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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This specification specifies the Customized Applications for Mobile network Enhanced Logic (CAMEL) CAMEL 
Application Part (CAP) within the digital cellular telecommunications system. 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS it will then be republished by ETSI with an identifying change of release 
date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997 

y the third digit is incremented when editorial only changes have been incorporated in the specification; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 
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1 Scope 



This Technical Specification specifies the CAMEL Apphcation Part (CAP) supporting the second phase of the network 
feature Customized Applications for Mobile network Enhanced Logic. CAP is based on a sub-set of the CS 1 Core INAP 
as specified by ETS 300 374-1 [14]. Descriptions and definitions provided by ETS 300 374-1 [14] are directly 
referenced by this standard in case no additions or clarifications are needed for the use in the CAP. 



2 Normative references 

References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] ETS 300 008 (1993): "Integrated Services Digital Network (ISDN); CCITT Signalling System 
No. 7; Message Transfer Part (MTP) to support international interconnection". 

[2] ETS 300 009 (1994): "Integrated Services Digital Network (ISDN); CCITT SignalHng System 

No. 7; Signalling Connection Control Part (SCCP) [connectionless and connection-oriented] to 
support international interconnection". 

[3] ETS 300 287 (1993): "Integrated Services Digital Network (ISDN); CCITT SignalUng System 

No. 7; Transaction Capabilities Application Part (TCAP) version 2". 

[4] ETS 300 356- 1 : "Integrated Services Digital Network (ISDN); CCITT Signalhng System No.7; 

ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services". 

[5] ETS 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling 

System No. one (DSSl); User-network interface layer 3 specification for basic call control; Part 1: 
Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[6] ITU-T Recommendation Q.773 (1993): "Specifications of Signalling System No.7; Transaction 

Capabilities formats and encoding". 

[7] ITU-T Recommendation Q.1218 (1995): "Interface Recommendation for intelligent network CSl". 

[8] ITU-T Recommendation Q.1400 (1993): "Architecture framework for the development of 

signalling and organization, administration and maintenance protocols using OSI principles". 

[9] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One 

(ASN.l)". 

[10] CCITT Recommendation X.209 (1988): "Specification of basic encoding rules for Abstract Syntax 

Notation One (ASN.l)". 

[II] CCITT Recommendation X.219 (1988): "Remote operations: Model, notation and service 
definition". 

[12] CCITT Recommendation X.229 (1988): "Remote operations: Protocol specification". 
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[13] ISO 9545 (1989): "Infonnation technology - Open Systems Interconnection - Application Layer 

structure". 

[14] ETS 300 374-1 (1994): "Intelligent Network (IN); Intelligent Network Capability Set 1 (CSl) Core 

Intelligent Network Application Protocol (INAP) Part 1: Protocol specification". 

[15] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part 

(MAP) specification". 

[16] GSM 03.78: "Digital cellular telecommunications system (Phase 2+); Customised Applications for 

Mobile network Enhanced Logic (CAMEL Phase 2) - stage 2". 

[17] CCITT Recommendation Q.713 : "Specifications of Signalling System No. 7; SCCP formats and 

codes". 

[18] ITU-T Recommendation X.680 (1994) I ISO/IEC 8824-1:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Specification of basic notation. 

[19] ITU-T Recommendation X.681 (1994) I ISO/IEC 8824-2:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Information object 
specification. 

[20] ITU-T Recommendation X.682 (1994) I ISO/IEC 8824-3:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Constraint specification. 

[21] ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Parameterization of ASN.l 
specifications. 

[22] ITU-T Recommendation X.690 (1994) I ISO/IEC 8825-1:1994, Information technology - Open 

Systems Interconnection - Specification of ASN.l encoding rules: Basic, Canonical, and 
Distinguished Encoding Rules. 

[23] ITU-T Recommendation X.880 (1994) I ISO/IEC 13712-1:1994, Information technology - Remote 

Operations: Concepts, model and notation. 

[24] GSM 09. 12 (prETS 300 646-1): "Digital cellular telecommunications system (Phase 2); SignalHng 

System No 7 - Application of ISUP version 2 for the ISDN-PLMN (GSM) signalling Interface. 

[25] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 

3 specification". 

[26] GSM 02.24: Digital cellular telecommunications system; Description of Charge Advice 

Information (CAI). 

[27] EN 301 070-1 (1997): "ISDN User Part (ISUP) version 3 interactions with the IntelUgent Network 

Application Part (INAP); Part 1: Protocol Specification [ITU-T Recommendation Q.1600 (1997), 
modified]". 

[28] GSM 03.03: Digital cellular telecommunications system (Phase 2+); Numbering, addressing and 

identification. 

[29] GSM 02.42: Digital cellular telecommunications system (Phase 2+); Network Identity and 

Timezone (NITZ) Service description. Stage 1 

[30] EN 301 140-1 (VI. 1): "IntelHgent Network (IN); IntelHgent Network CapabiUty Set 2 (CS2); 

Intelligent Network Application Protocol (INAP); Part 1: Protocol specification". 
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Abbreviations 



AC 

ACM 

AE 

ASE 

ASN.l 

BCSM 

CAP 

CSl 

CSI 

DP 

DSSl 

EDP 

EDP-N 

EDP-R 

FE 

FSM 

gsmSCF 

gsmSSF 

gsmSRF 

lAM 

ID 

IN 

INAP 

IP 

ISDN 

ISUP 

MACF 

MTP 

OCSI 

PE 

REL 

ROSE 

SACF 

SAO 

SCCP 

SCF 

SCME 

SCSM 

SEP 

SRF 

SSF 

SSME 

SSN 

TC 

TCAP 

TCSI 

TDP 

TDP-R 



Application Context 

Address Complete Message 

Application Entity 

Application Service Element 

Abstract Syntax Notation One 

Basic Call State Model 

CAMEL Application Part 

Capability Set 1 

CAMEL Subscription Information 

Detection Point 

Digital Subscriber Signalling System No. One 

Event Detection Point 

Event Detection Point - Notification 

Event Detection Point - Request 

Functional Entity 

Finite State Model 

GSM SCF 

GSM SSF 

GSM SRF 

Initial Address Message 

Identifier 

Intelligent Network 

Intelligent Network Application Protocol 

Intelligent Peripheral 

Integrated Services Digital Network 

ISDN User Part 

Multiple Association Control Function 

Message Transfer Part 

Originating CSI 

Physical Entity 

Release 

Remote Operations Service Element 

Single Association Control Function 

Single Association Object 

Signalling Connection Control Part 

Service Control Function 

SCF Management Entity 

SCF Call State Model 

Service Logic Program 

Specialised Resource Function 

Service Switching Function 

SSF Management Entity 

Sub-System Number 

Transaction Capabilities 

Transaction Capabilities Application Part 

Terminating CSI 

Trigger Detection Point 

Trigger Detection Point - Request 
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4 General 

4.1 Definition methodology 

The definition of the protocol is split into three Clauses: 

the definition of the Single/Multiple Association Control Function (S ACF/MACF) rules for the protocol 

(Clause 5); 

the definition of the operations transferred between entities (Clause 6); 

the definition of the actions taken at each entity (Clause 7). 

The S ACF/MACF rules are defined in prose. The operation definitions are in Abstract Syntax Notation 1 (ASN.l, see 
CCITT Recommendation X.208 [9]), and the actions are defined in terms of state transition diagrams. Further guidance 
on the actions to be performed on receipt of an operation can be gained from Clause 6 and from the relevant detailed 
procedures in Clause 7. 

The CAP is a Remote Operations Service Element (ROSE) user protocol (see CCITT Recommendations X.219 [11] and 
X.229 [12] and ITU-T Recommendation X.880 [23]). CAP uses the Basic Encoding Rules (see CCITT 
Recommendation X.209 [10] and ITU-T recommendation X.690 [22]). 
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4.2 Example physical scenarios 



The reader is referred to Intelligent Network Capability Set 1 (CSl) Core INAP [14] for details of the example physical 
scenarios. 



SCP 



SSF 
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ISUP 
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IP 


SSF 


SRF 







ISUP 



SCP 




Scenario 1 , Direct Patli To IP { Ref. CS1 cases b) & d)) 

Figurel (continued): Scenarios 
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SCP 




Initiating 
SSP 




Scenario 2a, Connection to IP via an Assisting SSF with relay function; IP co-located with Assisting gsmSSF 
(Ref. CS1 case c)) 



SCP 




Initiating 
SSP 



IP 



SRF 



Figurel (continued): Scenarios 
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Scenario 2b ; Connection to IP via an Assisting SSF with relay function; IP not co-located with Assisting gsmSSF 
(Ref CS1 case c)) 

SCP 





Scenario 3 , Connection to IP with relay function; IP co-located with gsmSSF { Ref CS1 case a)) 

Figurel (continued): Scenarios 
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Initiating 
SSP 



SRF 




IP 



Scenario 4, Connection to IP with relay function; IP not co-located witli gsmSSF (Ref CS1 case a)) 

Figurel (concluded): Scenarios 

The following table summarises the scenarios and corresponding interface connections that shall be supported by the 
CAP protocol. The following terms used in the table are defined as follows: 

Basic: Fully defined in CAP and may be used between any two network operators supporting CAP 

Bilateral: Additional clarifications of CAP capabilities between network operators and/or equipment 
vendors are necessary in order for CAP to be used between any two network operators 
supporting CAP. 

Direct: This refers to the case where CAP operations are exchanged between the gsmSRF and the 
gsmSCF via a transaction-level relationship established directly between the gsmSRF and 
the gsmSCF. 

Relay: This refers to the case where CAP operations are exchanged between the gsmSRF and the 
gsmSCF via two transaction-layer relationships. These relationships are: 

gsmSCF to/from gsmSSF, 

gsmSSF to/from gsmSRF. 

The gsmSSF sends operations it receives from the gsmSCF to the gsmSRF, and operations 
it receives from the gsmSRF to the gsmSCF. This is done without unpacking (and thus 
processing) of the relayed operations. 

The gsmSSF function referred to in the table is always located in an MSC or GMSC. 
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Table 1 



Scenario 


Interface Support 


gsmSSF 

to/from 

gsmSCF 


gsmSSF 

to/from 

gsmSRF 


gsmSSF 
to/from 
assisting SSF 


gsmSRF 

to/from 

gsmSCP 


assisting SSF 

to/from 

gsmSCF 


Scenario 1 

gsmSRF in IP connected to gsmSSF 
in MSC/GMSC via ISUP and accessed 
by gsmSCF through direct Signalling 
System No. 7 Connection 


See Note 1 


See Note 2 




See Notes 3 
and 6. 

For gsmSRF in 
VPLMN see 
Note 4; For 
gsmSRF in 
HPLMN see 
note 5 




Scenario 2a 

assisting gsmSSF in IVISC/GMSC 
connected to gsmSSF in IVISC/GMSC 
via ISUP. Assisting gsmSSF is 
accessed by gsmSCF through direct 
Signalling System No. 7 Connection. 

gsmSRF is co-located with assisting 
gsmSSF and accessed (by gsmSCF) 
by relay via assisting gsmSSF over an 
internal nodal interface 


See Note 1 
For gsmSRF in 
VPLMN see 
Notes 4 and 6; 
For gsmSRF in 
HPLMN see 
note 5 and 6 




See Note 2 




See Note 3 


Scenario 2b 

assisting gsmSSF in IVISC/GMSC 
connected to gsmSSF in MSC/GMSC 
via ISUP. Assisting gsmSSF is 
accessed by gsmSCF through direct 
Signalling System No. 7 Connection 

gsmSRF is in IP connected to 
assisting gsmSSF and accessed (by 
gsmSCF) by relay through ISUP or 
DSS1 via assisting SSF 


See Note 1 

See Notes 4 
and 6 


See Notes 4 
and 6 


See Note 2 




See Note 3 


Scenario 3 

gsmSRF is co-located with a gsmSSF 
in an MSC/GMSC and accessed by 
relay via gsmSSF over an internal 
nodal interface 


For gsmSRF in 
VPLMN see 
Notes 4; For 
gsmSRF in 
HPLMN see 
notes 5 and 6 


- 


- 


- 


- 


Scenario 4 

gsmSRF in IP connected to gsmSSF 
and accessed by gsmSCF by relay 
through ISUP or DSS1 via gsmSSF 


See Notes 4 
and 6 


See Notes 4 
and 6 


- 


- 


- 



NOTE 1 : Basic for establishment of interface when CorrelationID and SCFiD are transferred in the 

AssistingSSPIPRoutingAddress. Bilateral when CorrelationID and SCFiD are transferred by other means 
than in the AssistingSSPIPRoutingAddress. 

NOTE 2: Basic for establishment of interface when CorrelationID and SCFiD are transferred in the Called Party 

Number. Bilateral when CorrelationID and SCFiD are transferred by other means than in the Called Party 

Number. 

NOTE 3: Basic when the full Called Party Number received in VPLMN or HPLMN is transferred on its own in the 
AssistRequestlnstructions operation CorrelationID parameter to a gsmSCF in HPLMN. 
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Bilateral when CorrelationlD is extracted from Called Party Number in HPLMN/VPLMN and transferred 
on its own in AssistRequestlnstructions CorrelationlD field to a gsmSCF in HPLMN. 

NOTE 4: Bilateral for the playing of announcements via elementaryMessagelDs and variableMessages, playing of 
tones and the collection of DTMF digits. 

NOTE 5: Basic for the playing of announcements via elementaryMessagelDs and variableMessages, playing of 
tones and the collection of DTMF digits. 

NOTE 6: Bilateral for the playing of announcements via text to speech translation, translation of DTMF digits via 
speech to caller and the translation of voice to digits. 



4.3 CAP protocol architecture 



Many of the terms used in this subclause are based on the OSI Application Layer Structure as defined in ISO 9545 [13]. 
The CAP protocol architecture can be illustrated as shown in figure 2. 



Multiple Co-ordinated 
Interactions (case b) 



Application 
Process 


MACF 




SAO 


SAO 


S 
A 
C 

F 


ASE's 


S 
A 
C 

F 


ASE's 


TCAP 


TCAP 






SCCP 



or 



Single Interaction 
(case a) 

Application 
Process 



SAO 



S 
A 
C 

F 



ASE's 



TCAP 



SCCP 



MTP 



MTP 



Figure 2: CAP protocol architecture 

A PE has either single interactions (case a) or multiple co-ordinated interactions (case b) with other PEs. 

In case a, SACF provides a co-ordination function in using Application Service Elements (ASEs), which includes the 
ordering of operations supported by ASE(s), (based on the order of received primitives). The Single Association Object 
(SAO) represents the SACF plus a set of ASEs to be used over a single interaction between a pair of PEs. 

In case b, MACF provides a co-ordinating function among several S AOs, each of which interacts with an SAO in a 
remote PE. 

Each ASE supports one or more operations. Description of each operation is tied with the action of corresponding FE 
modelling (see GSM 03.78 [16] and Clause 7 of this TS). Each operation is specified using the operation macro 
described in figure 3. 



ETSI 



GSM 09.78 version 6.1.0 Release 1997 



21 



TS101 046 V6. 1.0 (1998-08) 



INAPUserASE's 



xyz OPERATION 

ARGUMENT {Parameterl , Parameter2,...} 
RESULT {Parameterl , Parameter2,...} 
LINKED {operations, operation4,...} 
ERRORS {errorl , error2....} 

errorl ERROR 

PARAMETER {Parameters, Parameter?,...} 
etc 



^' Operations 
to peer Results 
Errors 



TCAP ASE 



COMPONENT SUB-LAYER 



TRANSACTION SUB-LAYER 



I 



INVOKE 
^^ RETURN RESULT 
to peer RETURN ERROR 
REJECT 

^> BEGIN 

to peer CONTINUE 
END 
ABORT 
UNIDIRECTIONAL 



CONNECTIONLESS SCCP 

Figure 3: Operation description 

The use of the Application Context (AC) negotiation mechanism (as defined in ETS 300 287 [3]) allows the two 
communicating entities to identify exactly what their capabilities are and also what the capabilities required on the 
interface should be. This should be used to allow evolution through capability sets. 

If the indication of a specific AC is not supported by a pair of communicating FEs, some mechanism to pre-arrange the 
context shall be supported. 



4.4 CAP addressing 



The CAMEL Application Part makes use of the services offered by the Signalling Connection Control Part of signalling 
System No. 7. CCITT Blue Book or ITU-T (03/93) Recommendations Q.711 to Q.716 should be consulted for the full 
specification of SCCP. 



4.4.1 Sub-System Number (SSN) 



The use of SSN is a network operator option and values for intra-PLMN usage are network specific. A CAP SSN has 
been reserved for inter-PLMN use, as defined in GSM 03.03. 



4.4.2 Quality of service parameters 



The class (class or class 1) of SCCP is set as required by the application. However class 1 shall be requested by any 
application that can send more than 1 TCAP message to its peer (consecutive TR-CONTINUE) before receiving a 
response from its peer (TR-CONTINUE or TR-END). RESULT_NL should not be used. However, if RESULT_NL is 
used by the application (and thus segmentation is needed) class 1 shall be set by the application. 

According to Q.771, TC imposes no limitation on the number of segments. However if the peer TC users are certain that 
the Network Service used supports segmentation and reassembly of user data, the TC_RESULT_NL (RR_NL) facility is 
not necessary and should be avoided. 
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The return option may be used if requested by the appUcation (Network Operator to determine). 



4.4.3 SCCP addressing 



Within the GSM System there is a need to communicate between entities within the same PLMN and in different 
PLMNs. Using the CAMEL Application Part (CAP) for this function implies the use of Transaction Capabilities (TC) 
and the Signalling Connection Control Part (SCCP) of CCITT Signalling System No. 7. 

The format and coding of address parameters carried by the SCCP for that purpose shall comply with CCITT 
Recommendation Q.713 [17] with the following restrictions: 

1) Intra-PLMN addressing 

For communication between entities within the same PLMN, the use of SCCP addressing is network specific. 

2) Inter-PLMN addressing 

a) Called Party Address 

SSN indicator = a standardised SSN shall be used. The code point used shall be that specified for CAP in 
GSM 03.03; 

Point Code indicator = 0; 

Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

Routing indicator = (Routing on global title); 

b) Calling Party Address 

SSN indicator = a standardised SSN shall be used. The code point used shall be that specified for CAP in 
GSM 03.03; 

Point code indicator = 0; 

Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

Routing indicator = (Routing on Global Title). 

4.5 Definition And Usage Of LegID 

4.5.1 Definition Of LegID 

In CAP V.2, two types of LegID may be exchanged between the gsmSCF and the gsmSSF. These are: 

Sending Side LegID, and 

Receiving Side LegID 

Sending Side LegID is always used in operations sent from the gsmSCF to the gsmSSF, and Receiving Side LegID is 
always used in operations sent from the gsmSSF to the gsmSCF. 

4.5.2 Allocation Of LegID 

For all operations containing a LegID; 
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LegID = 1 shall always refer to the Calling Party, more specifically that party in the call present when InitialDP is 
sent to the gsmSCF, 

LegID = 2 shall always refer to the Called Party, more specifically that party in the call created as a result of the 
Connect or Continue operations. 

4.6 Compatibility IVIechanisms Used For CAP 

4.6.1 Introduction 

This subclause specifies the compatibility mechanisms that shall be used for CAP 

Two major categories of compatibility are handled by these mechanisms: 

compatibility with the ITU-T Recommendation Q.1218 [7] version of CSl INAP and the specification ETS 300 
374 -I version [14] of CSl INAP; 

compatibility with future versions of CAP. 

The second category has three sub-categories of compatibility dealt with in this subclause: 

minor changes to the CAP in future standardized versions: A minor change can be defined as a change of a 
functionality which is not essential for the requested CAMEL service. In case it is a modification of an existing 
function, it is acceptable that the addressed function is executed in either the older or the modified variant. If the 
change is purely additional, it is acceptable that it is not executed at all and that the peer Application Entity (AE) 
need not know about the effects of the change. For minor changes, a new AC is not required; 

major changes to the CAP in future standardized versions: A major change can be defined as a change of a 
functionality which is essential for the requested CAP service. In case it is a modification of an existing function, 
both application entities shall have a shared knowledge about the addressed functional variant. If the change is 
purely additional, the requested CAMEL service will not be provided if one of the application entities does not 
support the additional functionality. For major changes, a new AC is required; 

network specific changes to CAP: These additions may be of either the major or minor type for a service. No new 
AC is expected to be defined for this type of change. At the time of definition, the additions would not be 
expected to be included in identical form in future versions of the ETS. 

4.6.2 Definition of CAP compatibility mechanisms 

4.6.2.1 Compatibility mechanism for interworking of CAP with ETS! CSl Core INAP 
and ITU-T Q.1218 INAP 

On receipt of an operation according to ITU-T Recommendation Q. 1218 [7] or an operation according to ETS 300 374- 
1 [14] which is not part of the CAP or is part of the CAP but which contains parameters which are not part of the CAP: 

the gsmSSF shall apply the normal error handling for unknown operations or parameters, i.e. the normal error 
handling procedures as specified in Clause 10 shall be followed; 

the gsmSCF shall apply the normal error handling for unknown operations or parameters except for parameters in 
the InitialDP operation. All parameters specified in ITU-T Recommendation Q.1218 [7] and in ETS 300 374-1 
[14] for InitialDP shall be known by the gsmSCF, those not included in the CAP shall be ignored. 

Tagging of CAP addidons to ITU-T Recommendation Q.1218[7] and ETS 300 374-1 [14] are specified from 50 and 
upwards. 

4.6.2.2 Procedures for major additions to CAP 

In order to support the introduction of major functional changes, the protocol allows a synchronization between the two 
applications with regard to which functionaUty is to be performed. This synchronization takes place before the new 



ETSI 



GSM 09.78 version 6.1 .0 Release 1 997 24 TS 1 01 046 V6.1 .0 (1 998-08) 

function is invoked in either application entity, in order to avoid complicated fall-back procedures. The solution chosen 
to achieve such a synchronization is use of the AC negotiation provided in ETS 300 287 [3]. 

4.6.2.3 Procedures for minor additions to CAP 

The extension mechanism marker shall be used for future standardized minor additions to CAP. This mechanism 
implements extensions by including an "extensions marker" in the type definition. The extensions are expressed by 
optional fields that are placed after the marker. When an entity receives unrecognized parameters that occur after the 
marker, they are ignored (see ITU-T Recommendation X.680 [18]). 

4.6.2.4 Procedures for inclusion of network specific additions to CAP 

This mechanism is based on the ability to explicitly declare fields of any type via the Macro facility in ASN. 1 at the 
outermost level of a type definition. It works by defining an "ExtensionField" that is placed at the end of the type 
definition. This extension field is defined as a set of extensions, where an extension can contain any type. Each 
extension is associated with an identification that unambiguously identifies the extension. Refer to ITU-T 
Recommendation Q.1400 [8] for a definition of this mechanism. 
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5 Single/Multiple Association Control Function 

(SACF/MACF) rules 

5.1 Reflection of TCAP Application Context (AC) 

TCAP AC negotiation rules require that the proposed AC, if acceptable, is reflected in the first backwards message. 

If the AC is not acceptable, and the TC-User does not wish to continue the dialogue, it may provide an alternate AC to 
the initiator which can be used to start a new dialogue. 

NOTE: If the gsmSSF provides an AC which is not acceptable to the gsmSCF, then an alternate 

AC should not be returned. If the AC presented to the gsmSCF is not acceptable then this 
is most probably due to an error in subscriber data provisioning or an error at the 
gsmSSF. 

. Refer to ETS 300 287 [3] for a more detailed description of the TCAP AC negotiation mechanism. 

5.2 Sequential/parallel execution of operations 

In some cases, it may be necessary to distinguish whether operations should be performed sequentially or in parallel 
(synchronized). Operations which may be synchronized are: 

charging operations may be synchronized with any other operation. 

The method of indicating that operations are to be synchronized is to include them in the same message. Where it is 
impossible to execute one of the operations identified above until some other operation has progressed to some extent or 
finished, the sending PE (usually SCP) can control this by sending the operations in two separate messages. 

This method does not imply that all operations sent in the same message should be executed simultaneously, but simply 
that where it could make sense to do so (in the situations identified above) the operations should be synchronized. 

In case of inconsistency between the above mentioned generic rules and the FE-specific rules as specified in Clause 7, 
the FE-specific rules take precedence over the generic rules. 



Abstract syntax of the CAP 



This Clause specifies the abstract syntax for the CAP version 1, using ASN.l as defined in CCITT Recommendation 
X.208 [9] and ITU-T Recommendations X.680 [18], X.681 [19], X.682 [20] and X.683 [21]. 

The encoding rules which are applicable to the defined abstract syntax are the Basic Encoding Rules for ASN.l, defined 
in CCITT Recommendation X.209 [10] and ITU-T Recommendation X.690 [22] with the restrictions as described in 
ITU-T Recommendation Q.773 [6], § 4.1.1, modified by ETS 300 287 [3]. Additional encodings are cited for 
parameters used in existing ISUP (ETS 300 356-1 [4]) and DSSl (ETS 300 403-1 [5]) standards. 

For the ISUP and DSSl parameters used in the CAP, only the coding of the parameter value is coded as defined in ISUP 
or DSSl. The DSSl/ISUP defined parameter identifiers are removed and replaced by the CAP defined parameter 
identifiers. 

Where possible existing data types from the CSl ETSI Core INAP (ETS 300 374-1 [14]) and MAP (ETS 300 974 [15]) 
standards have been used. For future compatibility where parameter mappings in CSl ETSI Core INAP (ETS 300 374-1 
[14]) are not defined for functions imported from CS 1 ETSI Core INAP, but parameter mappings are defined in CS2 
ETSI Core INAP [30] then the parameter mappings in CS2 ETSI Core INAP [30] shall be used. 

The mapping of OPERATION and ERROR to TCAP components is defined in ITU-T Recommendation Q.773 [6] 
modified by ETS 300 287 [3]. The class of an operation is not stated explicitly but is specified in the ASN.l 
OPERATION MACRO, as follows: 
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class 1: both RESULT and ERRORS appears in the ASN.l OPERATION MACRO definition; 

class 2: only ERRORS appears in the ASN. 1 OPERATION MACRO definition; 

class 3: only RESULT appears in the ASN. 1 OPERATION MACRO definition; 

class 4: neither RESULT nor ERRORS appears in the ASN. 1 OPERATION MACRO definition. 

The abstract syntax for CAP is composed of several ASN.l modules describing operations, errors, and associated data 
types. The values (operation codes and error codes) are defined in a separate module. 

The module containing all the type definitions for CAP operations is CAP-Operations and is described in 
subclause 6.1. 

The module containing all the type definitions for CAP errors is CAP-Errors and is described in subclause 6.2. 

The module containing all the type definitions for CAP data types is CAP-DataTypes and is described in subclause 6.3. 

The module containing the operation codes and error codes for CAP is CAP-Codes and is described in subclause 6.4. 

All the AC definitions for CAP are described in subclause 6.5. 

The module containing the class definitions for CAP is CAP-Classes and is described in subclause 6.6. 



6.1 Operation types 



CAP-Operations {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
gsm-Network (1 ) modules (3) cap-operations (50) version2(l)} 

— This module contains the type definitions for the CAP v. 2 operations . 

DEFINITIONS : := 

BEGIN 

IMPORTS 

OPERATION 

FROM TCAPMessages {ccitt recommendation q 773 modules (2) messages (1) version2(2)} 

— error types 
Cancelled, 
CancelFailed, 
ETCFailed, 

Improper Caller Response, 

Mi ssingCustomer Record, 

MissingParameter, 

Parameter Out Of Range, 

Requestedinf oError, 

TaskRefused, 

UnavailableRe source, 

UnexpectedComponent Sequence, 

DnexpectedDataValue, 

UnexpectedParameter, 

UnknownLegID, 

SystemFailure 
FROM Core-INAP-CSl-Errors {ccitt (0) identif ied-organization (4 ) etsi(O) inDomain(l) in-network (1 ) 
modules (0) csl-errors (1 ) version2(l)} 

— CAP V.2 argument types 
ApplyChargingArg, 
ApplyChargingReportArg, 
AssistRequestlnstructionsArg, 
CallInf ormationReportArg, 
CallInf ormationRequestArg, 
CancelArg, 

ConnectArg, 

Connect ToRes our ceArg, 

EstablishTemporaryConnectionArg, 

Event ReportBCSMArg, 

Furni shChargingIn format lonArg, 

InitialDPArg, 

PlayAnnouncementArg, 

PromptAndCollectUserInf ormationArg, 

Receivedin format ionArg, 

ReleaseCallArg, 

RequestReportBCSMEventArg, 

Re set Timer Arg, 

SendChargingIn format ionArg, 

SpecializedResourceReportArg 
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FROM CAP-DataTypes {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1 ) 
modules (3) cap-datatypes (52) version2 (1) } ; 

— TYPE DEFINITIONS FOR CAP V.2 OPERATIONS FOLLOW 

— gsmSCF-gsmSSF operations 

ActivityTest ::= OPERATION 

RESULT 

— Direction: gsmSCF -> gsmSSF, Timer: T ^. 

— This operation is used to check for the continued existence of a relationship between the 

— gsmSCF and gsmSSF. If the relationship is still in existence, then the gsmSSF will respond. 

— If no reply is received, then the gsmSCF will assume that the gsmSSF has failed in some way 

— and will take the appropriate action. 

ApplyCharging ::= OPERATION 

ARGUMENT 

ApplyChargingArg 
ERRORS { 

MissingParameter, 

UnexpectedComponent Sequence, 

UnexpectedParameter, 

UnexpectedDataValue, 

Parameter Out Of Range, 

SystemFailure, 

TaskRefused 

} 

— Direction: gsmSCF -> gsmSSF, Timer: T 

— This operation is used for interacting from the gsmSCF with the gsmSSF CSE-controlled call 

— duration charging mechanism. 

ApplyChargingReport : := OPERATION 

ARGUMENT 

Apply Char gingReportArg 
ERRORS { 

MissingParameter, 

UnexpectedComponent Sequence, 

UnexpectedParameter, 

UnexpectedDataValue, 

Parameter Out Of Range, 

SystemFailure, 

TaskRefused 



— The ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF for the 

— CSE-controlled call duration charging mechanism. 

AssistRequestlnstructions : := OPERATION 

ARGUMENT 
AssistRequestlnstructionsArg 
ERRORS { 

Mi ssingCustomer Record, 

MissingParameter, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

— Direction: gsmSSF -> gsmSCF: gsmSRF -> gsmSCF, Timer: T^^-[ 

— This operation is used when there is an assist or handoff procedure and may be sent by the 

— gsmSSF or gsmSRF to the gsmSCF. This operation may be sent by the gsmSSF or gsmSRF to 

— the gsmSCF, when the initiating gsmSSF has set up a connection to the gsmSRF or to the 

— assisting gsmSSF as a result of receiving an EstablishTemporaryConnection from the gsmSCF. 

CalllnformationReport ::= OPERATION 

ARGUMENT 

Ca 1 1 In format ionReportArg 

— Direction : gsmSSF —> gsmSCF, Timer: T^j^^^ 

— This operation is used to send specific call information for a single call to the gsmSCF as 

— requested by the gsmSCF in a previous Callinf ormationRequest . 

CalllnformationRequest ::= OPERATION 

ARGUMENT 

Callinf ormationRequestArg 
ERRORS { 

MissingParameter, 

Parameter Out Of Range, 

Requestedinf oError, 

SystemFailure, 
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TaskRefused, 

UnexpectedComponent Sequence, 
Unexpected? arameter 



— Direction : gsmSCF —> gsmSSF^ Timer: T^j^-^^ 

— This operation is used to request the gsmSSF to record specific information about a single 

— call and report it to the gsmSCF (with a Callinf ormationReport operation) . 



Cancel 

ARGUMENT 

CancelArg 
ERRORS { 

CancelFailed 



OPERATION 



— Direction: gsmSCF -> gsmSSF, or gsmSCF -> gsmSRF, Timer: T^^j-, 

— This generic operation cancels the correlated previous operation or all previous requests. 

The following operations can be cancelled: PlayAnnouncement and PromptAndCollectUserInf ormation . 



Connect : : = 

ARGUMENT 

ConnectArg 
ERRORS { 

MissingParameter , 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 



OPERATION 



— Direction: gsmSCF -> gsmSSF, Timer: T^^^ 

— This operation is used to request the gsmSSF to perform the call processing actions to route 

— or forward a call to a specified destination. To do so, the gsmSSF may or may not use 

— destination information from the calling party (e.g., dialled digits) and existing call setup 

— information depending on the information provided by the gsmSCF. 



ConnectToResource ::= 

ARGUMENT 

Connect ToRes our ceArg 
ERRORS { 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 



OPERATION 



— Direction: gsmSCF -> gsmSSF, Timer: T^f-^ 

— This operation is used to connect a call from the physical entity containing the gsmSSF to the 

— physical entity containing the gsmSRF . 



Continue 



OPERATION 



— Direction: gsmSCF -> gsmSSF, Timer: T^^g 

— This operation is used to request the gsmSSF to proceed with call processing at the DP at 

— which it previously suspended call processing to await gsmSCF instructions (i.e., proceed to 

— the next point in call in the BCSM) . The gsmSSF continues call processing without 

— substituting new data from gsmSCF. 



Dis connect ForwardConnect ion 
ERRORS { 

SystemFailure, 
TaskRefused, 

UnexpectedComponent Sequence 
} 



OPERATION 



— Direction: gsmSCF -> gsmSSF, Timer: T^f^, 

— This operation is used to disconnect a forward temporary connection or a connection to a 

— resource. 



EstablishTemporaryConnection ::= 
ARGUMENT 

EstablishTemporaryConnectionArg 
ERRORS { 

ETCFailed, 
MissingParameter, 
SystemFailure, 
TaskRefused, 
UnexpectedComponent Sequence, 



OPERATION 
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UnexpectedDataValue, 
UnexpectedParameter 



— Direction: gsmSCF -> gsmSSF, Timer: Tgj-^, 

— This operation is used to create a connection to a resource (e.g. to 

— play an announcement, to collect user information); it implies the use of the assist procedure. 



Event ReportBCSM 
ARGUMENT 

EventReportBCSMArg 



OPERATION 



— Direction: gsmSSF -> gsmSCF, Timer: T , 

— This operation is used to notify the gsmSCF of a call-related event (e.g., BCSM events such 

— as answer or disconnect) previously requested by the gsmSCF in a RequestReportBCSMEvent 
operation. 

FurnishCharginglnformation : := OPERATION 
ARGUMENT 

Furn ishChargingIn format ionArg 
ERRORS { 

MissingParameter , 

TaskRefused, 

DnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

— Direction: gsmSCF -> gsmSSF, Timer: Tf^^i 

— This operation is used to request the gsmSSF to generate, register a call record or to 

— include some information in the default call record. The registered call record is intended 

— for off line charging of the call . 



InitialDP 

ARGUMENT 

InitialDPArg 
ERRORS { 

Mi ssingCustomer Record, 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 



OPERATION 



— Direction: gsmSSF -> gsmSCF, Timer: T^, 

— This operation is used after a TDP to indicate request for service. 



ReleaseCall 
ARGUMENT 

ReleaseCallArg 



OPERATION 



— Direction: gsmSCF -> gsmSSF, Timer: T^ 

— This operation is used to tear down an existing call at any phase of the call for all 

— parties involved in the call. 

RequestReportBCSMEvent ::= OPERATION 
ARGUMENT 

RequestReportBCSMEventArg 
ERRORS { 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 



— Direction: gsmSCF -> gsmSSF, Timer: 



rrb 



— This operation is used to request the gsmSSF to monitor for a call-related event (e.g., BCSM 

— events such as answer or disconnect), then send a notification back to the gsmSCF when the 
event is detected. 



ResetTimer ::= 

ARGUMENT 

Re set Timer Arg 
ERRORS { 

MissingParameter, 
TaskRefused, 

UnexpectedComponent Sequence, 
UnexpectedDataValue, 
UnexpectedParameter 



OPERATION 
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— Direction: gsmSCF > gsmSSF, Timer: Tj^f- 

— This operation is used to request the gsmSSF to refresh an application timer in the gsmSSF. 

SendCharginglnformation : := OPERATION 

ARGUMENT 

SendChargingI n format ionArg 
ERRORS { 

MissingParameter , 

UnexpectedComponent Sequence, 

OnexpectedParameter, 

Parameter Out Of Range, 

SystemFailure, 

TaskRefused, 

UnknownLegID 

} 

— Direction: gsmSCF > gsmSSF, Timer: T^^j_ 

— This operation is used to instruct the gsmSSF on the charging inf ormationwhich the gsmSSF 

— shall send to the Mobile Station by means of GSM access signalling. 

— gsmSCF-gsmSRF Operations 

— AssistRequestlnstructions 
gsmSRF -> gsmSCF 

— Refer to previous description of this operation in the gsmSCF-gsmSSF operations clause. 
Cancel 

gsmSCF -> gsmSRF 

— Refer to previous description of this operation in the gsmSCF-gsmSSF operations clause. 

PlayAnnouncement : := OPERATION 
ARGUMENT 

PlayAnnouncementArg 
ERRORS { 

Cancelled, 

MissingParameter , 

SystemFailure, 

UnavailableRe source, 

UnexpectedComponent Sequence, 

OnexpectedDataValue, 

HnexpectedParameter 

} 
LINKED { 

Special IzedResourceReport 

} 

— Direction: gsmSCF > gsmSRF, Timer: T„^ 

— This operation is to be used after Establish Temporary Connection (assist procedure with 

— a second gsmSSF) or a Connect to Resource (no assist) operation. It may be used for inband 

— interaction with a Mobile Station. In the former case, the gsmSRF is usually collocated 

— with the gsmSSF for standard tones (congestion tone etc.) or standard announcements. In 

— the latter case, the gsmSRF is always collocated with the gsmSSF in the MSC. Any error is 

— returned to the gsmSCF. When the gsmSRF is colocated with the gsmSSF, this operation is 

— relayed from the gsmSCF to the gsmSRF via the gsmSSF. The timer associated with this 

— operation must be of a sufficient duration to allow its linked operation to be correctly 

— correlated. 

PromptAndCollectUserlnformation : := OPERATION 

ARGUMENT 

Prompt An dCollectUser Inf ormat ionArg 
RESULT 

Receivedin format ionArg 
ERRORS { 

Cancelled, 

Improper Caller Response, 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnavailableRe source, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

— Direction: gsmSCF > gsmSRF, Timer: Tp^^ 

This operation is used to interact with a user to collect information. When the gsmSRF 

— is colocated with the gsmSSF, this operation is relayed from the gsmSCF to the gsmSRF 

— via the gsmSSF. 

SpecializedResourceReport : := OPERATION 

ARGUMENT 

Spec lalizedRes our ceReportArg 



ETSI 



GSM 09.78 version 6.1.0 Release 1997 



31 



TS101 046 V6. 1.0 (1998-08) 



— Direction: gsmSRF > gsmSCF, Timer: T^-^j- 

— This operation is used as the response to a PlayAnnouncement operation when the announcement 

— completed report indication is set. When the gsmSRF is colocated with the gsmSSF, this 

— operation is relayed from the gsmSRF to the gsmSCF via the gsmSSF. 

END 

Operation timers 

The following value ranges apply for operation specific timers in CAP: 

short: 1 to 20 seconds; 
medium: 1 to 60 seconds; 

long: 1 second to 30 minutes 

Table 2 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 

Table 2 



Operation Name 


Timer 


value 


Activitylest 


Tat 


short 


ApplyCharging 


Tac 


short 


ApplyChargingReport 


Tacr 


short 


AssistRequestlnstructions 


Tari 


short 


CalllnformationReport 


Tcirp 


short 


CalllnformationRequest 


Tcirq 


short 


Cancel 


Tcan 


short 


Connect 


^con 


short 


ConnectloResource 


Tctr 


short 


Continue 


^cue 


short 


DisconnectForwardConnection 


Tdfc 


short 


EstablishlemporaryConnection 


Tetc 


medium 


EventReportBCSIVI 


Terb 


short 


FurnishCharginglnformation 


Tfci 


short 


InitialDP 


TjdD 


short 


ReleaseCall 


Trc 


short 


RequestReportBCSMEvent 


Trrb 


short 


ResetTimer 


Trt 


short 


SendCharging Information 


Tsci 


short 


PlayAnnouncement 


Tpa 


long 


PromptAndCollectUserlnformation 


Tpc 


long 


SpecialisedResourceReport 


Tsrr 


short 



6.2 Error types 



Spare 
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6.3 Data types 



CAP-DataTypes {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 
modules (3) cap-datatypes (52) version2 (1) } 

— This module contains the type definitions for the CAP v. 2 data types. 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

IMPORTS 

— CAP Classes 

EXTENSION, 

ExtensionField 

FROM CAP-Classes {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 

modules (3) cap-classes (54 ) version2(l)} 

— This module contains the class definitions for CAP v. 2. 

— CSl Parameters 

CallingPartysCategory, 

Duration, 

HighLayerCompatibility , 

Integer 4, 

InvokelD, 

LegID, 

MiscCalllnfo, 

MonitorMode, 

Redirect ionlnformat ion, 

ServiceKey 
FROM Core-INAP-CSl-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) inDomain(l) 
in-network (1 ) modules (0) csl-datatypes (2 ) versionl(O)} 

BothwayThroughConnectionInd 
FROM Core-INAP-cs2-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) inDomain(l) 
in-network (1) cs-2(20) modules (0) cs2-datatypes (0) versionl (0) } 

IMSI, 

ISDN-AddressString, 

Ext-BasicServiceCode 
FROM MAP-CommonDataTypes { ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
gsm-Network (1 ) modules (3) map-CommonDataTypes (18) version3(3)} 

Locat ionlnformat ion. 
Subscriber St ate 

FROM MAP-MS-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) 
gsm-Network (1 ) modules (3) map-MS-DataTypes (11 ) version3(3)} 

CallRef erenceNumber , 

SuppressionOf Announcement 
FROM MAP-CH-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) 
gsm-Network (1) modules (3) map-CH-DataTypes (13) version3(3)} 

— TYPE DEFINITIONS FOR CAP V.2 DATA TYPES FOLLOW 

— Argument Data Types 

ApplyChargingArg ::= SEQUENCE { 

AchBillingChargingCharacteri sties [ 0] AChBillingChargingCharacteri sties, 

sendCalculationToSCPIndication [1] BOOLEAN DEFAULT FALSE, 

partyToCharge [2] SendingSidelD DEFAULT legl, 

extensions [3] SEQUENCE SIZE (1 .. numOf Extensions) OF 

ExtensionField OPTIONAL, 

} 

— The SendCalculationToSCPIndication parameter indicates that ApplyChargingReport operations 

— are expected from the gsmSSF. This parameter shall always be set to true. The partyToCharge 

— parameter indicates the party in the call to which the ApplyCharging operation should be 
applied. 

ApplyChargingReportArg ::= CallResult 
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AssistRequestlnstructionsArg 
correlation ID 
iPSSPCapabilities 
extensions 



SEQUENCE { 

[0] CorrelationID, 

[2] IPSSPCapabilities, 

[3] SEQUENCE SI ZE { 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 



— OPTIONAL denotes network operator specific use. The value of the correiationID may be the 

— Called Party Number supplied by the initiating gsmSSF. 



Call In format ionReportArg 

requestedinf ormationList 
extensions 

leglD 



SEQUENCE { 

[0] Requestedinf ormationList , 

[2] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 
[3] ReceivingSidelD OPTIONAL, 



CalllnformationRequestArg 

request edInformationTypeList 
extensions 

leglD 



SEQUENCE { 

[ 0] Requestedinf ormationTypeList, 

[2] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 
[3] SendingSidelD OPTIONAL, 



CancelArg 

invokelD 
allRequests 



CHOICE { 
[0] InvokelD, 
[1] NULL 



ConnectArg 

destinationRoutingAddress 
alertingPattern 
originalCalledPartylD 
extensions 

genericNumbers 
callingPartysCategory 
redirect ingParty ID 
redirect ion In format ion 
suppressionOf Announcement 
oCSIAppli cable 



SEQUENCE { 

[0] DestinationRoutingAddress, 

[1] AlertingPattern OPTIONAL, 

[6] OriginalCalledPartylD OPTIONAL, 

[10] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 

[14] GenericNumbers OPTIONAL, 

[28] CallingPartysCategory OPTIONAL, 

[29] RedirectingPartylD OPTIONAL, 

[30] Redirectionlnformation OPTIONAL, 

[55] SuppressionOf Announcement OPTIONAL, 

[56] OCSIApplicable OPTIONAL, 



} 



Connect ToRes our ceArg 
resource Address 

ipRoutingAddress 
none 



SEQUENCE { 
CHOICE { 

[0] IPRoutingAddress, 

[3] NULL 



extensions 

service Inter act ion Indicators Two 

} 



[4] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 
[7] ServicelnteractionlndicatorsTwo OPTIONAL, 



EstablishTemporaryConnectionArg 
as sistingSSP IPRoutingAddress 
correiationID 
scfID 
extensions 

service Inter act ion Indicators Two 

} 



SEQUENCE { 

[0] As sistingSSP IPRoutingAddress, 

[1] CorreiationID OPTIONAL, 

[3] ScfID OPTIONAL, 

[4] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 

[7] ServicelnteractionlndicatorsTwo OPTIONAL, 



Event ReportBCSMArg 
eventTypeBCSM 

event Sped ficInformationBCSM 
leglD 

miscCallInf o 
extensions 



SEQUENCE { 

[0] EventTypeBCSM, 

[2] EventSpecificInformationBCSM OPTIONAL, 

[3] ReceivingSidelD OPTIONAL, 

[4] MiscCalllnfo DEFAULT {messagelype request], 

[5] SEQUENCE SIZE ( 1 .. numOf Extensions ) OF 

ExtensionField OPTIONAL, 



Furni shChargingIn format ionArg 



FCIBillingChargingCharacteri sties 



ETSI 



GSM 09.78 version 6.1.0 Release 1997 



34 



TS101 046 V6. 1.0 (1998-08) 



InitialDPArg 
serviceKey 
calledPartyNumber 
callingPartyNumber 
callingPartysCategory 
iPSSPCapabilities 
locationNumber 
originalCalledPartylD 
extensions 

highLayerCompatibility 

additionalCallingPartyNumber 

bearerCapability 

eventTypeBCSM 

redirect ingParty ID 

redirect ionlnformat ion 

iMSI 

subscriber St ate 

locat ionlnformat ion 

ext-basicServiceCode 

callReferenceNumber 

mscAddress 

calledPartyBCDNumber 

timeAndTimezone 

gsm-ForwardingP ending 



SEQUENCE { 

[0] ServiceKey, 

[2] CalledPartyNumber OPTIONAL, 

[3] CallingPartyNumber OPTIONAL, 

[5] CallingPartysCategory OPTIONAL, 

[8] IPSSPCapabilities OPTIONAL, 

[10] LocationNumber OPTIONAL, 

[12] OriginalCalledPartylD OPTIONAL, 

[15] SEQUENCE SI ZE ( 1 .. numOf Extensions ) OF 

ExtensionFleld OPTIONAL, 

[23] HigtiLayerCompatibility OPTIONAL, 

[25] AdditionalCallingPartyNumber OPTIONAL, 

[27] BearerCapability OPTIONAL, 

[28] EventTypeBCSM OPTIONAL, 

[29] RedirectingPartylD OPTIONAL, 

[30] Redirectionlnformation OPTIONAL, 

[50] IMSI OPTIONAL, 

[51] SubscriberState OPTIONAL, 

[52] Locationlnformation OPTIONAL, 

[53] Ext-BasicServiceCode OPTIONAL, 

[54] CallReferenceNumber OPTIONAL, 

[55] ISDN-AddressString OPTIONAL, 

[56] CalledPartyBCDNumber OPTIONAL, 
[57] TimeAndTimezone OPTIONAL, 

[58] NULL OPTIONAL, 



— If iPSSPCapabilities is not present tlien tills denotes tliat a colocated gsmSRF is not 

— supported by tlie gsmSSF. If present, tlien tlie gsmSSF supports a colocated gsmSRF capable 

— of playing announcements via elementaryMessagelDs and variableMessages, tlie playing of 

— tones and tlie collection of DTMF digits. Otlier supported capabilities are explicitly 

— detailed in tlie IPSSPCapabilities parameter itself. 



PlayAnnouncementArg 

inf ormationToSend 

dis connect FromlPForbidden 

request Announcement Complete 

extensions 



SEQUENCE { 

[0] Inf OrmationToSend, 
[1] BOOLEAN 
[2] BOOLEAN 

[3] SEQUENCE SI ZE ( 1 .. numOf Extensions ) 
ExtensionFleld 



DEFAULT TRUE, 
DEFAULT TRUE, 
OF 
OPTIONAL, 



} 



PromptAndCollectUserInf ormationArg 
collectedinf o 
dis connect FromlPForbidden 
inf ormationToSend 
extensions 



SEQUENCE { 
[0] Collectedlnfo, 
[1] BOOLEAN 
[2] Inf OrmationToSend 

[3] SEQUENCE SI ZE ( 1 .. numOf Extensions ) 
ExtensionFleld 



DEFAULT TRUE, 
OPTIONAL, 
OF 
OPTIONAL, 



ReceivedInf ormationArg 
digitsResponse 



CHOICE { 
[0] Digits 



ReleaseCallArg 



Cause 



Request Report BCSMEventArg 
bcsmEvents 
extensions 



SEQUENCE { 

[0] SEQUENCE SIZE ( 1 . . numOf BCSMEvent s ) OF BCSMEvent, 

[2] SEQUENCE SIZE ( 1 .. numOf Extensions ) OF 

ExtensionFleld OPTIONAL, 



Indicates the BCSM related events for notification . 



Re set Timer Arg 
timerlD 
timervalue 
extensions 



SEQUENCE { 
[0] TimerlD 
[1] TimerValue, 

[2] SEQUENCE SI ZE ( 1 .. numOf Extensions ) 
ExtensionFleld 



DEFAULT tssf. 



OF 
OPTIONAL, 



} 



SendCliargingInf ormationArg : := SEQUENCE { 

sCIBillingCtiargingCliaracterl sties [0] SCIBillingChargingCliaracteri sties, 
partyToCharge [1] SendingSidelD, 

extensions [2] SEQUENCE SIZE (1 .. numOf Extensions) 

ExtensionFleld 



OF 
OPTIONAL, 



} 
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SpecializedResourceReportArg ::= NULL 

— Common Data Types 

AChBillingChargingCharacteristics ::= CHOICE { 

timeDurationCharging [50] SEQUENCE { 

maxCallPeriodDuration [0] INTEGER (1.. 864000), 

releaselfdurationExceeded [1] ReleaselfDurationExceeded OPTIONAL, 

tariffSwitchlnterval [2] INTEGER (1.. 86400) OPTIONAL 

} 
} 

— The AChBillingChargingCharacteristics parameter specifies the charging related information to be 

— provided by the gsmSSF and the conditions on which this information has to be reported back to 

— the gsmSCF with the ApplyChargingReport operation. tariffSwitchlnterval is measured in 1 second 

— units. maxCallPeriodDuration is measured in 100 millisecond units 

AdditionalCallingPartyNumber ::= Digits 

— Indicates the Additional Calling Party Number. 
AlertingPattern ::= OCTET STRING (SIZE (1)) 

— The encoding of this parameter is as defined in GSM 09.02 [Reference 15] . 

AOCBeforeAnswer ::= SEQUENCE { 

aOCInitial [0] CAI-GSM0224, 

aOCSubsequent [1] AOCSubsequent OPTIONAL 

} 

AOCSubsequent ::= SEQUENCE { 

CAI-GSM0224 [0] CAI-GSM0224 , 

tariffSwitchlnterval [1] INTEGER (1.. 86400) OPTIONAL 

} 

— tariffSwitchlnterval is measured in 1 second units 
ApplicationTimer ::= INTEGER (0..2047) 

— Used by the gsmSCF to set a timer in the gsmSSF. The timer is in seconds. 
AssistingSSPIPRoutingAddress ::= Digits 

— Indicates the destination address of the gsmSRF for the assist procedure. 

BCSMEvent ::= SEQUENCE { 

eventTypeBCSM [0] EventTypeBCSM, 

monitorMode [1] MonitorMode, 

leglD [2] LegID OPTIONAL, 

dPSpecificCriteria [30] DPSpecif icCriteria OPTIONAL 

} 

— Indicates the BCSM Event information for monitoring. 

BearerCapability ::= CHOICE { 

bearerCap [0] OCTET STRING (SIZE (2 . .maxBearerCapabilityLength) ) 

} 

— Indicates the type of bearer capability connection to the user. For bearerCap, the value as 

— described in ISUP (ETS 300 356-1 [4], User Service Information) shall be used. 



CAI-GSM0224 
el 
e2 
e3 
e4 
e5 



e7 
} 



SEQUENCE { 






[0] 


INTEGER 





.8191) 


[1] 


INTEGER 





.8191) 


[2] 


INTEGER 





.8191) 


[3] 


INTEGER 





.8191) 


[4] 


INTEGER 





.8191) 


[5] 


INTEGER 





.8191) 


[6] 


INTEGER 





.8191) 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL 



— Indicates Charge Advice Information to the Mobile Station. For information regarding 

— parameter usage, refer to GSM 02.40 [26] . 

CalledPartyBCDNumber ::= OCTET STRING (SIZE (minCalledPartyBCDNumberLength .. 

maxCalledPartyBCDNumber Length) 

— Indicates the Called Party Number, including service selection information. Refer to GSM 

— 04.08 [25] for encoding. This data type carries only the "type of number", "numbering plan 

— identification" and "number digit" fields defined in [25]; it does not carry the "called 

— party BCD number lEI" or "length of called party BCD number contents". 

CalledPartyNumber ::= OCTET STRING (SIZE (minCalledPartyNumberLength .. 
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maxCalledPartyNumberLength) ) 
Indicates the Called Party Number. Refer to ETS 300 356-1 [4] for encoding. 



CallingPartyNumber 



OCTET STRING (SIZE (minCallingPartyNumberLength 
maxCallingPartyNumberLength) ) 



Indicates the Calling Party Number. Refer to ETS 300 356-1 [4] for encoding. 



CallResult 

timeDurationChargingResult 
partyToCharge 
time In format ion 

callActive 



CHOICE { 
[50] SEQUENCE { 
[0] ReceivingSidelD, 
[1] TimeInf ormation, 
[2] BOOLEAN 



DEFAULT TRUE 



} 

This parameter provides the gsmSCF with the charging related information previously requested 

— using the ApplyCharging operation. This shall include the partyToCharge parameter as 

— received in the related ApplyCharging operation to correlate the result to the request. 



Cause 



OCTET STRING (SIZE (minCauseLength 



maxCauseLength) ) 



— Indicates the cause for interface related information. Refer to the ETS 300 356-1 [4] Cause 

— parameter for encoding. For the use of Cause and Location values refer to Q.850. 

— Shall only include the cause value. 



CollectedDigits 

minimumNbOf Digits 
maximumNbOf Digits 
endOfReplyDigit 
cancelDigit 
startDigit 
firstDigitXimeOut 
inter DigitTimeOut 
err or Treatment 
inter ruptableAnnInd 
voiceinf ormation 
voiceBack 



SEQUENCE { 



[0] 
[1] 
[2] 
[3] 
[4] 
[5] 
[6] 
[7] 



[10 



INTEGER (1 . .127) 
INTEGER (1 . .127) , 
OCTET STRING (SIZE 
OCTET STRING (SIZE 
OCTET STRING (SIZE 
INTEGER (1 . .127) 
INTEGER (1 . .127) 
Err or Treatment 
BOOLEAN 
BOOLEAN 
BOOLEAN 



DEFAULT 1, 

(1 . .2) ) OPTIONAL, 

(1 . .2) ) OPTIONAL, 

(1. .2) ) OPTIONAL, 

OPTIONAL, 
OPTIONAL, 
DEFAULT stdErrorAndlnfo, 
DEFAULT TRUE, 
DEFAULT FALSE, 
DEFAULT FALSE 



— The use of voiceBack and the support of vaice recognition via voiceinf ormation is 

— network operator specific. The endOfReplyDigit, cancelDigit, and startDigit parameters 
have been designated as OCTET STRING, and are to be encoded as BCD, one digit per octet 

— only, contained in the four least significant bits of each OCTET. 

— The usage is service dependent. 



Collectedinf o 

CollectedDigits 



CHOICE [ 

[0] CollectedDigits 



CorrelationID 



Digits 



— used by gsmSCF for correlation with a previous operation. Refer to clauses 9.5 and 

— for a description of the procedures associated with this parameter. 



J. 15 



DateAndTime 



OCTET STRING (SIZE (7)) 



DateAndTime is BCD encoded. The year d 
the first octet, and the year digit in 
The year digit indicating decade occup 
indicating the year within the decade 
The most significant month digit occup 
significant month digit occupies bits 
The most significant day digit occupie 
day digit occupies bits 4-7 of the fou 
The most significant hours digit occup 
digit occupies bits 4-7 of the fifth o 
The most significant minutes digit occ 
significant digit occupies bits 4-7 of 
The most significant seconds digit occ 
significant digit occupies bits 4-7 of 
For the encoding of digits in an octet 



igit indicating millenium occupies bits 0-3 of 

dicating century occupies bits 4-7 of the first octet. 

ies bits 0-3 of the second octet, whilst the digit 

occupies bits 4-7 of the second octet. 

ies bits 0-3 of the third octet, and the least 

4-7 of the third octet. 

s bits 0-3 of the fourth octet, and the least significant 

rth octet . 

ies bits 0-3 of the fifth octet, and the least significant 

ctet. 

upies bits 0-3 of the sixth octet, and the least 

the sixth octet, 
upies bits 0-3 of the seventh octet, and the least seconds 

the seventh octet . 
refer to the timeAndtimezone parameter. 



DestinationRoutingAddress 



SEQUENCE SIZE (1) OF CalledPartyNumber 



Indicates the Called Party Number. 



Digits 



::= OCTET STRING (SIZE (minDigitsLength .. maxDigitsLength) ) 



— Indicates the address signalling digits. Refer to the ETS 300 356-1 [4] Generic Number 

— and Generic Digits parameters for encoding. The coding of the subfields "NumberQualif ier^' 
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in Generic Number and "Type Of Digits" in Generic Digits are irrelevant to the CAP, the 

— ASN . 1 tags are sufficient to identify the parameter. The ISUP format does not allow to 

— exclude these subfields, therefor the value is network operator specific. 

— The following parameters should use Generic Number: 
AdditionalCallingPartyNumber for InitialDP 

— AssistingSSPIPRoutingAddress for EstablishTemporaryConnection 

— CorrelationID for AssistRequestlnstructions 

— The following parameters should use Generic Digits: 

— CorrelationID in EstablishTemporaryConnection 

— number in VariablePart 

— digitsResponse in Receivedinf ormationArg 

— Note that when CorrelationID is transported in Generic Digits, then the digits shall 

— always be BCD encoded. 



DPSpecificCriteria 

applicationTimer 



CHOICE { 

[1] ApplicationTimer 



The gsmSCF may set a timer in the gsmSSF for the NoAnswer event. If the user does not 
answer the call within the allocated time, the gsmSSF reports the event to the gsmSCF . 



Err or Treatment 

stdErrorAndInf o 

help 

repeatPrompt 



ENUMERATED { 
(0), 
(1), 
(2) 



— StdErrorAndInf o means returning the "ImproperCallerResponse" error in the event of an error 

— condition during collection of user info. 



Event SpecificInformationBCSM 

routeSelectFailureSpecif icinf o 
f ailureCause 



CHOICE { 
[2] SEQUENCE { 
[0] Cause 



OPTIONAL, 



oCalledPartyBusySpecificInfo 
busyCause 



[3] SEQUENCE { 
[0]Cause 



OPTIONAL, 



oNoAnswerSpecif icInf o 

— no specific info defined- 



[4] SEQUENCE { 



oAnswerSpecif icInf o 

— no specific info defined- 



[5] SEQUENCE { 



oDisconnectSpecificInfo 
releaseCause 



[7] SEQUENCE { 
[0] Cause 



OPTIONAL, 



}, 

tBusySpecif icInf o 
busyCause 



[8] SEQUENCE { 
[0] Cause 



OPTIONAL, 



}, 

tNoAnswerSpecif icInf o 

— no specific info defined- 



SEQUENCE { 



tAnswerSpecif icInf o 

— no specific info defined- 



[10] SEQUENCE { 



tDisconnectSpecificInfo 
releaseCause 



[12] SEQUENCE { 
[0] Cause 



OPTIONAL, 



oNotReachableSpecif icInf o 
releaseCause 



[50] SEQUENCE { 
[0] Cause 



OPTIONAL, 



tNotReachableSpecif icInf o 
releaseCause 



[51] SEQUENCE { 
[0] Cause 



OPTIONAL, 



— Indicates the call related information specific to the event. 



EventTypeBCSM 

collectedinf o 



ENUMERATED { 
(2), 
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rout eSelect Failure 

oCalledPartyBusy 

oNoAnswer 

oAnswer 

oDisconnect 

oAbandon 

termAt tempt Author! zed 

tBusy 

tNoAnswer 

tAnswer 

tDisconnect 

tAbandon 

oNotReachable 

tNotReachable 



(4), 

(5), 

(6), 

(7), 

(9), 

(10), 

(12), 

(13), 

(14), 

(15), 

(17), 

(18), 

(50), 

(51) 



— Values collectedinf o and termAttemptAuthorized can only be 
used for TDPs. 

ExtensionField ::= SEQUENCE { 

type EXTENSION. Sid ( { SupportedExtensions } ) , 

— shall identify the value of an EXTENSION type 

criticality EXTENSION. Scriticality ( {SupportedExtensions} {@type} ) , 

value [1] EXTENSION. SExtensionType ( {SupportedExtensions} {@type} ) 



— This parameter indicates an extension of an argument data type. Its content is network 
operator specific 



FCIBillingChargingCharacteri sties 
fCIBCCCAMELsequencel 
freeFormatData 

partyToCharge 



CHOICE { 
[50] SEQUENCE { 

[0] OCTET STRING (SIZE (minFCIBillingChargingLength . . 

maxFCIBillingChargingLength) ) , 

[1] SendingSidelD DEFAULT legl 



This parameter indicates the billing and/or charging characteristics. 



GenericNumber 



OCTET STRING (SI ZE (minGenericNumberLength . . 
maxGenericNumberLength) ) 



— Indicates a generic number. Refer to ETS 300 356-1 [4] Generic number for encoding. 
GenericNumbers ::= SET SIZE (1 . . numOf GenericNumbers) OF GenericNumber 



Inbandinf o 

mess age ID 

numberOf Repetitions 

duration 

interval 



SEQUENCE { 

[0] MessagelD, 

[1] INTEGER (1 . .127) 

[2] INTEGER (0. .32767) 

[3] INTEGER (0. .32767) 



OPTIONAL, 
OPTIONAL, 
OPTIONAL 



— Interval is the time in seconds between each repeated announcement. Duration is the 

— total amount of time in seconds, including repetitions and intervals. The end of 

— announcement is either the end of duration or numberOf Repetitions, whatever comes 

— first. Duration with value indicates infinite duration. 



Inf ormationToSend 
inbandinf o 
tone 
} 



CHOICE { 
[0] Inbandlnfo, 
[1] Tone 



IPRoutingAddress ::= CalledPartyNumber 

— Indicates the routing address for the IP. 



IPSSPCapabilities 



OCTET STRING (SIZE (minlPSSPCapabilitiesLength . . 
maxIPSSPCapabilitiesLength) ) 



Indicates the gsmSRF resources available. The parameter has two parts, a standard and a 
bilateral part. The standard part indicates capabilities defined as optional in CAP V.2 
that shall be recognised (but not necessarily supported) by a CAP V.2 gsmSCF . The bilateral 
part contains further information that is not specified in this standard, but which is set 
according to bilateral agreements between network operators and/or equipment vendors. 
The last octet of the standard part is indicated by bit 7 being set to 0, otherwise Bit 7 of 
a standard part octet is set to 1 indicating that the standard part continues in the following 
octet. Coding is as follows: 



Octet 1 
Bit Value 



Standard Part for CAP V.2 
Meaning 



ETSI 



GSM 09.78 version 6.1.0 Release 1997 



39 



TS101 046 V6. 1.0 (1998-08) 











1 


1 







1 


2 







1 


3 







1 


4 







1 


5 


- 


6 


- 


7 







1 



IPRoutingAddress not supported 

IPRoutingAddress supported 

VoiceBack not supported 

VoiceBack supported 

Voiceinf ormation not supported, via speech recognition 

Voiceinf ormation supported, via speech recognition 

Voiceinf ormation not supported, via voice recognition 

Voiceinf ormation supported, via voice recognition 

Generation of voice announcements from Text not supported 

Generation of voice announcements from Text supported 

Reserved 

Reserved 

End of standard part 

This value is reserved in CAP V.2 



— Octets 2 to 4 

LegType 

legl LegType 
leg2 LegType 

LocationNumber 



Bilateral Part: Network operator / equipment vendor specific 
::= OCTET STRING (SIZE(l)) 



'Ol'H 
'02'H 



OCTET STRING (SIZE (minLocationNumberLength . 
maxLocationNumberLength) ) 



Indicates the Location Number for the calling party. Refer to ETS 300 356-1 [4] for encoding. 



Mess age ID 

elementaryMessagelD 
text 

messageContent 

attributes 

}, 

element aryMes sage IDs 

variableMessage 

elementaryMessagelD 
variableParts 



CHOICE { 

[0] Integer4, 

[1] SEQUENCE { 

[0] lASString (SIZE (minMessageContentLength . . 

maxMessageContentLength) ) , 
[1] OCTET STRING (SIZE (minAttributesLength . . 

maxAttributesLength) ) OPTIONAL 

[29] SEQUENCE SIZE (1 . . numOfMessagelDs) OF Integer4, 
[30] SEQUENCE { 

[0] Integer4, 

[1] SEQUENCE SIZE (1..5) OF VariablePart 



Use of the text parameter is network operator/equipment vendor specific. 



OriginalCalledPartylD 



::= OCTET STRING (SIZE (minOriginalCalledPartylDLength .. 
maxOriginalCalledPartylDLength) ) 



— Indicates the original called number. Refer to ETS 300 356-1 [4] Original Called Number 

— for encoding. 



OCSIApplicable 



NULL 



Indicates that the Originating CAMEL Subscription Information, if present, shall be 

— applied on the outgoing call leg created with a Connect operation. For the use of this 

— parameter see GSM 03.78 [16]. 

ReceivingSidelD ::= [1] LegType 

— used to identify LegID in operations sent from gsmSSF to gsmSCF 



Redirect ingParty ID 



::= OCTET STRING (SIZE (minRedirectingPartylDLength .. 
maxRedirectingPartylDLength) ) 



— Indicates redirecting number. Refer to ETS 300 356-1 [4] Redirecting number for encoding. 



Releaself DurationExceeded 
tone 



SEQUENCE { 

BOOLEAN DEFAULT FALSE, 



extensions [10] SEQUENCE SIZE (1 .. numOf Extensions) 

ExtensionField 
} 

— Indicates that the call shall be released, with optional warning tone. 



OF 
OPTIONAL 
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Requestedinf ormationList 

Requestedinf ormationTypeList 

Requestedinf ormat ion 

requestedinf ormationType 
requestedinf ormat ionValue 



SEQUENCE SIZE ( 1 . . numOf Inf oltems ) OF Requestedinf ormation 

SEQUENCE SIZE ( 1 .. numOf Inf oltems ) OF Requestedinf ormationType 

: := SEQUENCE { 

[0] Requestedinf ormationType, 
[1] Requestedinf ormationValue 



Requestedinf ormationType 

call At tempt El apsedlime 
callStopTime 

callConnectedEl apsedlime 
releaseCause 



ENUMERATED { 
(0), 
(1), 
(2), 
(30) 



Requestedinf ormationValue 

call At tempt El apsedlimeValue 
callStopTimeValue 
callConnectedEl apsedlimeValue 
releaseCauseValue 



CHOICE { 

[0] INTEGER (0. .255) , 

[1] DateAndTime, 

[2] Integer4, 

[30] Cause 



— The callAttemptElapsedTimeValue is specified in seconds. The unit for the 

— callConnectedElapsedTimeValue is 100 milliseconds. 

ScfID ::= OCTET STRING (SIZE (minScf IDLength . .maxScf IDLength) ) 

— defined by network operator. Indicates the SCF identifier. 

SCIBillingChargingCharacteristics : := CHOICE { 

aOCBef oreAnswer [50] AOCBef oreAnswer, 

aOCAfterAnswer [51] AOCSubsequent 



— Indicates AOC information to be sent to a Mobile Station 
SendingSidelD : := [0] LegType 

— used to identify LegID in operations sent from gsmSCF to gsmSSF 



Service Inter act ion Indicators Two 
bothwaylhroughConnectionlnd 



SEQUENCE { 

[2] BothwaylhroughConnectionlnd 



OPTIONAL 



Timeinf ormation 

t ime I fNoTariff Switch 
timelf Tariff Switch 



CHOICE { 

[0] TimelfNoTariffSwitch, 

[1] TimelfTariffSwitch 



— Indicates call duration information 
TimelfNoTariffSwitch ::= INTEGER (0 .. 864000) 

— TimelfNoTariffSwitch is measured in 100 millisecond intervals 



TimelfTariffSwitch 

timeSincelariff Switch 
tariff Switchlnterval 



SEQUENCE { 

[0] INTEGER(0. .864000) , 

[1] INTEGER(1 . .864000) 



OPTIONAL 



timeSincelariff Switch and tariff Switchlnterval are measured in 100 millisecond intervals 



TimerlD 
tssf 



: : = ENUMERATED { 
(0) 



— Indicates the timer to be reset. 
TimerValue ::= Integer 4 

— Indicates the timer value (in seconds) 
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TimeAndTimezone ::= OCTET STRING (SIZE (minTimeAndTimezoneLength. . 

maxTimeAndTimezoneLength) 

— Indicates the time and timezone, relative to GMT. This parameter BCD encoded. 

— The year digit indicating millenium occupies bits 0-3 of the first octet, and the year 

— digit indicating century occupies bits 4-7 of the first octet. 

— The year digit indicating decade occupies bits 0-3 of the second octet, whilst the digit 

— indicating the year within the decade occupies bits 4-7 of the second octet. 

— The most significant month digit occupies bits 0-3 of the third octet, and the least 

— significant month digit occupies bits 4-7 of the third octet. 

— The most significant day digit occupies bits 0-3 of the fourth octet, and the least 

— significant day digit occupies bits 4-7 of the fourth octet. 

— The most significant hours digit occupies bits 0-3 of the fifth octet, and the least 

— significant hours digit occupies bits 4-7 of the fifth octet. 

— The most significant minutes digit occupies bits 0-3 of the sixth octet, and the least 

— significant minutes digit occupies bits 4-7 of the sixth octet. 

— The most significant seconds digit occupies bits 0-3 of the seventh octet, and the least 

— significant seconds digit occupies bits 4-7 of the seventh octet. 

— The timezone information occupies the eigth octet. For the encoding of Timezone refer to 

— Reference [29], GSM 02.42. 

— The BCD digits are packed and encoded as follows: 

— Bit 



7 6 


5 




4 13 2 10 






2nd di 


-gi 


-t 


1st digit 


Octet 


1 


3rd di 


-gi 


.t 


4th digit 


Octet 


2 


nth di 


-gi 


-t 


n- 


-1th digit 


Octet 


m 


0000 






digit 









0001 






digit 


1 






0010 






digit 


2 






0011 






digit 


3 






0100 






digit 


4 






0101 






digit 


5 






0110 






digit 


6 






0111 






digit 


7 






1000 






digit 


8 






1001 






digit 


9 






1010 






spare 








1011 






spare 








1100 






spare 








1101 






spare 








1110 






spare 








1101 






spare 









— where the leftmost bit of the digit is either bit 7 or bit 3 of the octet. 

Tone : := SEQUENCE { 

tonelD [0] Integer4, 

duration [1] Integer 4 OPTIONAL 

} 

— The duration specifies the iength of the tone in seconds, value indicates infinite duration . 

VariablePart ::= CHOICE { 

integer [0] Integer4, 

number [1] Digits, 

— Generic digits 
time [2] OCTET STRING (SIZE (2)), 

— HH:MM, BCD coded 
date [3] OCTET STRING (SIZE (4)), 

— YYYYMMDD, BCD coded 
price [4] OCTET STRING (SIZE (4)) 
} 

— Indicates the variable part of the message. Time is BCD encoded. 

— The most significant hours digit occupies bits 0-3 of the first octet, and the least 

— significant digit occupies bits 4-7 of the first octet. The most significant minutes digit 

— occupies bits 0-3 of the second octet, and the least significant digit occupies bits 4-7 
of the second octet. 

— Date is BCD encoded. The year digit indicating millenium occupies bits 0-3 of the first octet, 

— and the year digit indicating century occupies bits 4-7 of the first octet. The year digit 

— indicating decade occupies bits 0-3 of the second octet, whilst the digit indicating the year 

— within the decade occupies bits 4-7 of the second octet. 

— The most significant month digit occupies bits 0-3 of the third octet, and the least 

— significant month digit occupies bits 4-7 of the third octet. The most significant day digit 

— occupies bits 0-3 of the fourth octet, and the least significant day digit occupies bits 4-7 
of the fourth octet. 

— Price is BCD encoded. The digit indicating hundreds of thousands occupies bits 0-3 of the 

— first octet, and the digit indicating tens of thousands occupies bits 4-7 of the first octet. 
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The digit indicating thousands occupies bits 0-3 of the second octet, whilst the digit 

— indicating hundreds occupies bits 4-7 of the second octet. The digit indicating tens occupies 

— bits 0-3 of the third octet, and the digit indicating to 9 occupies bits 4-7 of the third 

— octet. The tenths digit occupies bits 0-3 of the fourth octet, and the hundredths digit 

— occupies bits 4-7 of the fourth octet. 

— For the encoding of digits in an octet, refer to the timeAndtimezone parameter 

— Definition of range constants 



minAttributesLength 

maxAttributesLength 

maxBearerCapabilityLength 

minCalledPartyBCDNumber Length 

maxCalledPartyBCDNumber Length 

minCalledPartyNumber Length 

maxCalledPartyNumber Length 

minCallingPartyNumber Length 

maxCallingPartyNumber Length 

minCauseLength 

maxCauseLength 

minDigitsLength 

maxDigitsLength 

minFCIBillingChargingLength 

maxFCIBillingChargingLength 

minGenericNumber Length 

maxGenericNumber Length 

minlPSSPCapabilitiesLength 

maxIPSSPCapabilitiesLength 

minLocationNumber Length 

maxLocationNumber Length 

minMessageContent Length 

maxMessageContent Length 

minOriginalCalledPartylDLength 

maxOriginalCalledPartylDLength 

minRedirectingPartylDLength 

maxRedirectingPartylDLength 

minScf IDLength 

maxScf IDLength 

minTimeAndTimezoneLength 

maxTimeAndTimezoneLength 

numOfBCSMEvents 

numOf Ext ens ions 

numOfGenericNumbers 

numOflnfoI terns 

numOfMessagelDs 



INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


11 


INTEGER : 


: = 


1 


INTEGER : 


: = 


41 


INTEGER : 


: = 


3 


INTEGER : 


: = 


12 


INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


2 


INTEGER : 


: = 


2 


INTEGER : 


: = 


3 


INTEGER : 


: = 


11 


INTEGER : 


: = 


1 


INTEGER : 


: = 


40 


INTEGER : 


: = 


3 


INTEGER : 


: = 


11 


INTEGER : 


: = 


1 


INTEGER : 


: = 


4 


INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


1 


INTEGER : 


: = 


127 


INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


2 


INTEGER : 


: = 


10 


INTEGER : 


: = 


8 


INTEGER : 


: = 


8 


INTEGER : 


: = 


10 


INTEGER : 


: = 


10 


INTEGER : 


: = 


5 


INTEGER : 


: = 


4 


INTEGER : 


: = 


5 
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6.4 Operation and error codes 



CAP-Codes {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) cap- 
-codes (53) version2 (1) } 

— This module contains the operation and error code assignments for the CAP v. 2 application 

— protocol . 

DEFINITIONS : := 
BEGIN 

— OPERATION AND ERROR CODE ASSIGNMENTS FOR THE CAP V.2 PROTOCOL FOLLOWS 
IMPORTS 

operation types 

ActivityTest, 

ApplyCharging, 

ApplyChargingReport , 

As si stRequest Inst ructions, 

Cal 1 In format ionReport, 

Callinf ormationRequest , 

Cancel, 

Connect, 

Connect ToRe source. 

Continue, 

Dis connect ForwardConnect ion, 

EstablishTemporaryConnection, 

EventReportBCSM, 

FurnishChargingIn format ion, 

InitialDP, 

PlayAnnouncement , 

Pr ompt An dCollectUser Information, 

ReleaseCall, 

RequestReportBCSMEvent, 

ResetTimer, 

SendChargingIn format ion, 

SpecializedResourceReport 
FROM CAP-Operations { ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 
modules (3) cap-operations (50) version2(l)} 

CSl error types 

Cancelled, 

CancelFailed, 

ETCFailed, 

Improper Caller Response, 

Mi ssingCustomer Record, 

MissingParameter, 

Parameter Out Of Range, 

Requestedinf oError, 

TaskRefused, 

OnavailableRe source, 

OnexpectedComponent Sequence, 

UnexpectedDataValue, 

DnexpectedParameter, 

OnknownLegID 
FROM Core-INAP-CSl-Errors {ccitt(O) identif ied-organization (4 ) etsi(O) inDomain(l) in-network (1) 
modules (0) csl-errors (1) version2 (1) } 

— CAP error types 

SystemFailure 
FROM CAP-Errors {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 
modules (3) cap-errors (51) version2 (1) } ; 

— the operations are grouped by the identified ASEs. 

— gsmSCF activation ASE 

initialDP InitialDP 

— SCF/gsmSRF activation of assist ASE 
as si StRequest Inst ructions As si stRequest Inst ructions 

— Assist connection establishment ASE 
establishlemporaryConnection EstablishTemporaryConnection 



localValue 



localValue 16 



localValue 17 
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— Generic disconnect resource ASE 

dis connect ForwardConnect ion Dis connect ForwardConnect ion 

— Non-assisted connection estabiishment ASE 

connect ToRe source Connect ToRe source 

— Connect ASE (elementary gsmSSE function) 
connect Connect 

— Call handling ASE (elementary gsmSSE function) 



releaseCall 

— BCSM Event handling ASE 

requestReportBCSMEvent 
event Report BCSM 

gsmSSE call processing ASE 

continue 

— Timer ASE 
resetTimer 

— Billing ASE 
furnishChargingIn format ion 

— Charging ASE 

apply Charging 
apply Char gingReport 

— Call report ASE 

callinf ormationReport 
callinf ormationRequest 

— Signalling control ASE 
sendChargingIn format ion 

— Specialized resource control ASE 

pi ay Announcement 

promptAndCollect User In format ion 
specializedResourceReport 

— Cancel ASE 

cancel 

Activity Test ASE 
activityTest 

— ERROR codes 



ReleaseCall 



RequestReportBCSMEvent 
Event Report BCSM 



Continue 



ResetTimer 



FurnishChargingIn format ion 



Apply Charging 
Apply Char gingReport 



Callinf ormationReport 
Callinf ormationRequest 



SendChargingIn format ion 



PI ay Announcement 

PromptAndCollect User In format ion 
SpecializedResourceReport 



Cancel 



ActivityTest 



localValue If 



localValue 19 



localValue 20 



localValue 22 



localValue 23 
localValue 24 



localValue 31 



localValue 33 



localValue 34 



localValue 35 
localValue 36 



localValue 44 
localValue 45 



localValue 



localValue 47 
localValue 48 
localValue 49 



localValue 53 



localValue 55 



cancelled 

cancelFailed 

eTCFailed 

improper Caller Response 

mi ssingCustomer Record 

missingParameter 

parameter Out Of Range 

requestedinf oError 

systemFailure 

taskRefused 

unavailableRe source 

unexpectedComponent Sequence 

unexpectedDataValue 

unexpectedParameter 

unknownLegID 



Cancelled 

CancelFailed 

ETCFailed 

Improper Caller Response 

Mi ssingCustomer Record 

MissingParameter 

Parameter Out Of Range 

Requestedinf oErr or 

SystemFailure 

TaskRefused 

UnavailableRe source 

UnexpectedComponent Sequence 

UnexpectedDataValue 

UnexpectedParameter 

UnknownLegId 



localValue 





localValue 


1 


localValue 


3 


localValue 


4 


localValue 


6 


localValue 


7 


localValue 


8 


localValue 


10 


localValue 


11 


localValue 


12 


localValue 


13 


localValue 


14 


localValue 


15 


localValue 


16 


localValue 


17 



END 
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6.5 Application Service Elements 



CAP-ASEs {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) cap- 
ases(55) version2(l)} 

— This module contains grouping of operations by the identified ASEs for the CAP v,2 application . 

DEFINITIONS : := 
BEGIN 

— GROUPING OF OPERATIONS BY THE IDENTIFIED ASEs FOR THE CAP V.2 PROTOCOL FOLLOWS 
IMPORTS 

macros 

APPLICATION-SERVICE-ELEMENT 

FROM Remote-Operations-Notation-Extension { joint-iso-ccitt remote-operations (4 ) notation- 
extension (2) } 

operation codes 

activityTest, 

applyCharging, 

applyChargingReport , 

as si stRequest Inst ructions, 

callinf ormationReport, 

callinf ormationRequest , 

cancel, 

connect, 

connect ToRe source, 

continue, 

dis connect ForwardConnect ion, 

establishTemporary Connect ion, 

event ReportBCSM, 

furnishchargingin format ion, 

initialDP, 

playAnnouncement , 

promptAndCollectUser Information, 

releaseCall, 

requestReportBCSMEvent , 

resetximer, 

sendChargingIn format ion, 

specializedResourceReport 

FROM CAP-Codes {ccitt{0) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 
modules (3) cap-codes (53) version2 (1) } 

— APPLICATION SERVICE ELEMENTS 



GSM-SCF-activation-ASE 



APPLICATION-SERVICE-ELEMENT 



— consumer is gsmSSF 

CONSUMER INVOKES { 
initialDP 



GSM-SCF-GSM-SRF-activation-of-assist-ASE 



APPLICATION-SERVICE-ELEMENT 



— consumer is gsmSSF/gsmSRF 
CONSUMER INVOKES { 

as si StRequest Inst ructions 

} 
Assist-connection-establishment-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
establishTemporaryConnection 



APPLICATION-SERVICE-ELEMENT 



Generic-dis connect -res our ce-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
dis connect ForwardConnect ion 



APPLICATION-SERVICE-ELEMENT 



Non-assisted-connection-establishment-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
connect ToRe source 



APPLICATION-SERVICE-ELEMENT 
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Connect-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
connect 



APPLICATION-SERVICE-ELEMENT 



Call-handling-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
releaseCall 

} 



APPLICATION-SERVICE-ELEMENT 



BCSM-event-handling-ASE 

— consumer is gsmSSF 
CONSUMER INVOKES { 
event ReportBCSM 



APPLICATION-SERVICE-ELEMENT 



— supplier is gsmSCF 
SUPPLIER INVOKES { 
requestReportBCSMEvent 



GSM-SSF-call-processing-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
continue 



APPLICATION-SERVICE-ELEMENT 



Timer-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
resetTimer 



APPLICATION-SERVICE-ELEMENT 



Billing-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
furnishChargingIn format ion 



APPLICATION-SERVICE-ELEMENT 



Charging-ASE 

— consumer is gsmSSF 
CONSUMER INVOKES { 
applyChargingReport 



APPLICATION-SERVICE-ELEMENT 



— supplier is gsmSCF 
SUPPLIER INVOKES { 
applyCharging 



Call-report-ASE 

— consumer is SSF 
CONSUMER INVOKES { 
callinf ormationReport 



APPLICATION-SERVICE-ELEMENT 



— supplier is SCF 
SUPPLIER INVOKES { 
callinf ormationRequest 



Signal ling-control-ASE 
— supplier is SCF 
SUPPLIER INVOKES { 
sendChargingIn format ion 



APPLICATION-SERVICE-ELEMENT 



Sped all zed-res our ce-control-ASE 

— consumer is SSF/gsmSRF 
CONSUMER INVOKES { 
special IzedResourceReport 



APPLICATION-SERVICE-ELEMENT 



— supplier is SCF 
SUPPLIER INVOKES { 

playAnnouncement , 
promptAndCollectUser Information 



Cancel-ASE 

— supplier is SCF 
SUPPLIER INVOKES { 



APPLICATION-SERVICE-ELEMENT 
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cancel 



} 



Activity-test-ASE 

— supplier Is gsmSCF 
SUPPLIER INVOKES { 
activityTest 

} 



APPLICATION-SERVICE-ELEMENT 



END 



6.6 Application contexts 



APPLICATION-CONTEXT MACRO 

BEGIN 

TYPE NOTATION 

VALUE NOTATION 

Symmetric 

Initiator Consumer Of 

Responder Consumer Of 

ASEList 

ASE 



Symmetric I InitiatorConsumerOf ResponderConsumerOf I empty 

value (VALUE OBJECT IDENTIFIER) 

"OPERATIONS OF" "{" ASEList "}" 

"INITIATOR CONSUMER OF" "{" ASEList "}" I empty 

"RESPONDER CONSUMER OF" "{" ASEList "}" I empty 

ASE j ASEList ", " ASE 

type — shall reference an APPLICATION-SERVICE-ELEMENT type. 



END 



CAP-v2-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT 
— dialogue Initiated by gsmSSF with InltlalDP 
INITIATOR CONSUMER OF { 

GSM-SCF-activation-ASE, 

Assist-connection-establishment-ASE, 

Non-assisted-connection-establishment-ASE, 

Generic-dis connect -res our ce-ASE, 

Connect-ASE, 

Call-handling-ASE, 

BCSM-event-handling-ASE, 

Charging-ASE, 

GSM-SSF-call-processing-ASE, 

Timer-ASE, 

Billing-ASE, 

Call-report-ASE, 

Signal ling-control-ASE, 

Specialized-resource-control-ASE, 

Cancel-ASE, 

Activity-test-ASE 



::= {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1 ) ac(0) 
cap-gsmssf-to-gsmscf (50) version2 (1) } ; 
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CAP-v2-assist-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT 

— dialogue initiated by gsmSSF with AssistRequestlnstructions 
INITIATOR CONSUMER OF { 

GSM-SCF-GSM-SRF-activation-of-assist-ASE, 

Generic-dis connect -res our ce-ASE, 

Non-assisted-connection-establishment-ASE, 

Timer-ASE, 

Special ized-resource-control-ASE, 

Cancel-ASE, 

Activity-test-ASE 

} 
::= {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) ac(0) 
cap-assist-handof f-gsmssf-to-gsmscf (51) version2 (1) } ; 

CAP-v2-gsmSRF-to-gsmSCF-AC APPLICATION-CONTEXT 

— dialogue initiated by gsmSRF with AssistRequestlnstructions 
INITIATOR CONSUMER OF { 

GSM-SCF-GSM-SRF-activation-of-assist-ASE, 

Special! zed-res our ce-control-ASE, 

Cancel-ASE, 

Activity-test-ASE 

} 
::= {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1 ) ac (0) cap-gsmSRF-to- 
gsmscf(52) version2 (1 ) } ; 



6.7 Classes 



CAP-Classes {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) 
cap — classes (54) version2(l)} 

— This module contains the class definitions for CAP v. 2. 

DEFINITIONS : := 

BEGIN 

IMPORTS 

ROS-OBJECT-CLASS, Code, 

CONNECT I ON-P ACKAGE 

FROM Remote-Operations-Information-Objects { joint-iso-ccitt remote-operations (4 ) 

inf ormationOb jects (5) versionl (0) } 

EXTENSION ::= CLASS { 

& Ext en si on Type, 

Scriticality CriticalityType DEFAULT ignore, 

Sid Code 

} 
WITH SYNTAX { 

EXTENSION-SYNTAX SExtensionType, 

CRITICALITY Scriticality , 

IDENTIFIED BY Sid 

} 

CriticalityType ::= ENUMERATED { 

Ignore (0) , 

Abort (1) 
} 

— Only value Global OBJECT IDENTIFIER is used for Sid 

— Only the value ignore (0) is used for Scriticality. 

— Example of addition of an extension named ^ ^Some Network Specific Indicator' ' of type 

— BOOLEAN, with criticality ^ ^ignore' ' and to be identified with object ID ^^ccitt(O) 

— identif ied-organization (4 ) organisation (x) gsm(x) capextension' ' : 

— Example of definition using the above information object class: 

— SomeNetworkSpecificIndicator EXTENSION ::= { 

— EXTENSION-SYNTAX BOOLEAN 

— CRITICALITY ignore 

— IDENTIFIED BY global : xxxxxx 

— } 

firstExtension EXTENSION ::= { 

EXTENSION-SYNTAX NULL, 

CRITICALITY ignore, 

IDENTIFIED BY global :{ xxxxxx } 

} 
SupportedExtensions EXTENSION ::= {firstExtension — full set of network operator extensions — } 
END 
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7 Application entity procedures 

The description of the apphcation entity procedures for CAMEL Phase 2 can be found in GSM 03.78 [16]. 

8 Error procedures 

This subclause defines the generic error procedures for the CAP. The error procedure descriptions have been divided in 
two subclauses, subclause 8.1 listing the errors related to CAP operations and subclause 8.2 listing the errors related to 
error conditions in the different FEs which are not directly related to the CAP operations. 

The gsmSSF states which are referred to in this section are described in GSM 03.78 [16]. The operations 

Play Announcement, PromptAndCollectUserlnformation and SpecialisedResourceReport refer to states in the gsmSRF 

SRSM which are described in ETS 300 374-1 [14] as well as to states in GSM 03.78 [16]. 

8.1 Operation related error procedures 

The following subclauses define the generic error handling for the operation related errors. The errors are defined as 
operation errors in Clause 6. Errors which have a specific procedure for an operation are described in Clause 9 with the 
detailed procedure of the related operation. 

The TCAP services which are used for reporting operation errors are described in Clause 10. All errors which can be 
detected by the ASN. 1 decoder already may have been detected during the decoding of the TCAP message and indicated 
by the TC error indication "MistypedParameter". 

The gsmSSF states which are referred to in this section are described in GSM 03.78 [16]. The operations 

Play Announcement, PromptAndCollectUserlnformation and SpecialisedResourceReport refer to states in the gsmSRF 

SRSM which are described in ETS 300 374-1 [14] as well as to states in GSM 03.78 [16]. 

8.1.1 Spare 

8.1.2 Cancelled 

8.1 .2.1 General description 
8.1.2.1.1 Error description 

The error "Cancelled" gives an indication to the gsmSCF that the cancellation, as it was requested by the SCF, of a 
specific operation, has been successful. The gsmSCF is only able to cancel certain predefined gsmSCF->gsmSRF 
operations. 

8.1 .2.2 Operations gsmSCF->gsmSRF 

Play Announcement 
PromptAndCollectUserlnformation 

Procedures at responding entity (gsmSRF) 

A) Receiving Cancel 

precondition: SRSM state User Interaction 

postcondition: SRSM state User Interaction 

The indicated PA or P&C is terminated if it is presently executing or deleted from the buffer. If the indicated PA or 

P&C is already executed this causes a failure ("CancelFailed"). 

B) Sending Cancel error 

precondition: SRSM state User Interaction 

postcondition: SRSM state User Interaction 
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After returning the "Cancelled" error the gsmSRF stays in the same state. The execution of the indicated PA or P&C is 
aborted, i.e. the gsmSRF remains connected and the next PA or P&C is executed if available. 

8.1.3 CancelFailed 

8.1 .3.1 General description 

8.1.3.1.1 Error description 

This error is returned by Cancel if the cancelling of an operation, as requested by the gsmSCF, was not successful. 
Possible failure reasons are: 

unknownOperation, when the InvokelD of the operation to cancel is not known to gsmSRF (this may also happen 
in case the operation has already been completed); 

1 tooLate, when the invokelD is known but the execution of the operation is in a stadium that it cannot be cancelled 
anymore. For instance the announcement is finished but the SpecializedResourceReport has not been sent to the 
gsmSCF yet. The conditions for the occurrence of failure reason "tooLate" may be implementation dependent; 

2 operationNotCancellable, when the invokelD points to an operation that the gsmSCF is not allowed to cancel. 

8.1.3.1.2 Argument description 

PARAMETER SEQUENCE { 

problem [0] ENUMERATED { 
unknownOperation (0) , 
tooLate (1) , 

operationNotCancellable (2) } , 
operation [1] InvokelD 
} 
— The operation failed to be cancelled. 

8.1 .3.2 Operations gsmSCF->gsmSRF 

Cancel 

Procedures at responding entity (gsmSRF) 

A) Receiving Cancel. However, the indicated PA or P&C is not known, or already executed. This causes a failure, 
CancelFailed. 

precondition: SRSM state User Interaction 

postcondition: SRSM state User Interaction 

or SRSM state Idle 

B) Sending CancelFailed error 

precondition: SRSM state User Interaction 

or SRSM state Idle 

postcondition: SRSM state User Interaction 

or SRSM state Idle 

After returning the CancelFailed the gsmSRF stays in the same state. 

8.1.4 ETCFailed 

8.1.4.1 General description 

8.1.4.1.1 Error description 

ETCFailed is an error from gsmSSF to gsmSCF, indicating the fact that the establishment of a temporary connection to 
an assisting SSF or gsmSRF was not successful (e.g. receiving a "Backwards Release" after sending the lAM). 
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8.1 .4.2 Operations gsmSCF->gsmSSF 

EstablishTemporaryConnection 

Procedures at responding entity (gsmSSF) 

gsmSSF receives ETC from gsmSCF but the establishment of the connection fails, resulting in the returning of the 

ETCFailed error to the gsmSCF 

precondition: gsmSSF FSM Waiting for Instructions 

postcondition: gsmSSF FSM Waiting for Instructions 

No further error treatment. 

8.1.5 ImproperCallerResponse 

8.1 .5.1 General description 
8.1.5.1.1 Error description 

The format of the user input has been checked by the gsmSRF and does not correspond to the required format as it was 
defined in the initiating P&C operation. 

8.1 .5.2 Operations gsmSCF->gsmSRF 

PromptAndCoUectUserlnformation 

Procedures at responding entity (gsmSRF) 

A) gsmSRF receives P&C 

precondition: SRSM state Connected 

or SRSM state User Interaction 

postcondition: SRSM state User Interaction 

B) response from caller is not correct, gsmSRF returns ImproperCallerResponse to gsmSCF 

precondition: SRSM state User Interaction 

postcondition: SRSM state User Interaction 

gsmSRF waits for a new operation from gsmSCF. This may be a new P&C or PA. 

8.1.6 MissingCustomerRecord 

8.1.6.1 General description 
8.1.6.1.1 Error description 

The SLP could not be found in the gsmSCF, because the required customer record does not exist or the requested SLPI, 
indicated by CorrelationID in the AssistRequestlnstructions does not exist anymore. 

8.1 .6.2 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 
InitialDP 

Procedures at invoking entity (gsmSSF) 

gsmSSF receives error "MissingCustomerRecord" 

precondition: gsmSSF state Waiting for Instructions 

postcondition: gsmSSF state Idle 

The GMSC/VMSC handles the call according to the Default Call Handling parameter of the valid CSI. 
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8.1 .6.3 Operations SRF->SCF 

AssistRequestlnstructions 
Procedures at invoking entity (SRF) 

A) Sending operation 

precondition: SRSM state2 Connected 
postcondition: SRSM state2 Connected 

B) SRF receives error "MissingCustomerRecord" 

precondition: SRSM state2 Connected 
postcondition: SRSM state 1 Idle 

SRF initiated Disconnect. 

8.1.7 MissingParameter 

8.1 .7.1 General description 
8.1.7.1.1 Error description 

There is an error in the received operation argument. The responding entity cannot start to process the requested 
operation because the argument is incorrect: an expected optional parameter which is essential for the application is not 
included in the operation argument. 

8.1 .7.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging CalllnformationRequest 

FumishCharginglnformation RequestReportBCSMEvent 

ResetTimer SendCharginglnformation 

Call Associated/Call Processing 

Connect ConnectToResource 

EstablishTemporaryConnection 

Procedures at responding entity (gsmSSF) 

precondition: (1) gsmSSF appropriate state. 

(2) gsmSSF operation received, appropriate event occurred, 
postcondition: (1) gsmSSF transition to the same state. 

The gsmSSF detects the error in the received operation. The error parameter is returned to inform the gsmSCF of this 
situation. 

8.1 .7.3 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 

ApplyChargingReport 

InitialDP 

Procedures at invoking entity (gsmSSF) 

A) Sending operation 

precondition: SSF FSM any state in which the above operations can be transferred 
postcondition: SSF FSM any state as result of the transfer of any of the above operations 

B) gsmSSF receives error "MissingParameter" 
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precondition: gsmSSF any state as result of the transfer of any of the above operations. 

postcondition: gsmSSF state Idle 

After receiving this error, the gsmSSF returns to the state Idle, the GMSCA'MSC handles the call according to the 

Default Call Handling parameter of the valid CSI. In case of an assisting SSF, tine temporary connection is 

released by the assisting SSF. 

8.1 .7.4 Operations gsmSCF->gsmSRF 

PlayAnnouncement 
PromptAndCoUectUserlnformation 

Procedures at responding entity (gsmSRF) 

precondition: SRSM state Connected 

or SRSM state User Interaction 

postcondition: SRSM state User Interaction 

The SRSM detects that a required parameter is not present in the operation argument. The error parameter 
MissingParameter is used to inform the gsmSCF of this situation. The gsmSCF should take the appropriate actions to 
treat this error. 

8.1 .7.5 Operations SRF->SCF 

AssistRequestlnstructions 
Procedures at invoking entity (SRF) 

A) Sending operation 

precondition: SRSM state2 Connected 
postcondition: SRSM state2 Connected 

B) Receiving error 

precondition: SRSM state2 Connected 
postcondition: SRSM state 1 Idle 

8.1.8 ParameterOutOf Range 

8.1.8.1 General description 
8.1.8.1.1 Error description 

The responding entity cannot start the processing of the requested operation because an error in a parameter of the 
operation argument is detected: a parameter value is out of range. 

8.1 .8.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging 

CalllnformationRequest 

SendCharginglnformation 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .8.3 Operations gsmSSF->gsmSCF 

ApplyChargingReport 

Refer to subclause 8.1.7 for the appropriate error procedures. 
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8.1.9 RequestedlnfoError 

8.1 .9.1 General description 

8.1.9.1.1 Error description 

The RequestedlnfoError is an immediate response to the CalllnformationRequest operation, indicating that the requested 
information is not known to the gsmSSF or is not available. 

8.1.9.1.2 Argument description 

PARAMETER ENUMERATED { 

unknownRequestedlnfo (1) , 
requestedlnfoNotAvailable (2) 

} 

8.1 .9.2 Operations gsmSCF->gsmSSF 

CalllnformationRequest 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.10 SystemFailure 

8.1 .1 0.1 General description 

8.1.10.1.1 Error description 

This error is returned by a PE if it was not able to fulfil a specific task as requested by an operation, and recovery is not 
expected to be completed within the current call instance. 

8.1.10.1.2 Argument description 

PARAMETER 

UnavailableNetworkResource 

UnavailableNetworkResource : := ENUMERATED { 

unavailableResources (0) , 

componentFailure (1) , 

basicCallProcessingException (2) , 

resourceStatusFailure (3) , 

endUserFailure (4) 
} 

8.1 .1 0.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging CalllnformationRequest 

RequestReportBCSMEvent SendCharginglnformation 

Call Associated/Call Processing 

Connect ConnectToResource 

DisconnectForwardConnection EstablishTemporaryConnection 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 0.3 Operations gsmSSF->gsmSCF 

InitialDP 
ApplyChargingReport 

Refer to subclause 8.1.7 for the appropriate error procedures. 
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8.1 .1 0.4 Operations gsmSCF->gsmSRF 

PlayAnnouncement 
PromptAndCoUectUserlnformation 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.11 TaskRefused 

8.1 .11 .1 General introduction 

8.1.11.1.1 Error description 

This error is returned by a PE if it was not able to fulfil a specific task as requested by an operation, and recovery is 
expected to be completed within the current call instance. 

8.1.11.1.2 Argument description 

PARAMETER ENUMERATED { 
generic (0) , 
unobtainable (1) , 
congestion (2) 

} 

8.1 .1 1 .2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging CalllnformationRequest 

FurnishCharginglnformation RequestReportBCSMEvent 

ResetTimer SendCharginglnformation 

Call Associated/Call Processing 

Connect ConnectToResource 

DisconnectForwardConnection EstablishTemporaryConnection 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 1 .3 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 

InitialDP 

ApplyChargingReport 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 1 .4 Operations gsmSCF->gsmSRF 

PromptAndCoUectUserlnformation 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.11.5 Operations SRF->SCF 

AssistRequestlnstructions 

Refer to subclause8.1.7 for the appropriate error procedures. 
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8.1.12 UnavailableResource 

8.1 .1 2.1 General description 
8.1.12.1.1 Error description 

The gsmSRF is not able to perform its function (i.e. play a certain announcement and/or collect specific user 
information), and cannot be replaced. A reattempt is not possible. 

8.1 .1 2.2 Operations gsmSCF->gsmSRF 

Play Announcement 
PromptAndCollectUserlnformation 

Procedures at responding entity (gsmSRF) 

A) gsmSRF receiving PA or P&C 

precondition: gsmSRF state Connected; if initial PA or P&C 

or gsmSRF state User Interaction; if not initial PA or P&C 

B) gsmSRF is not able to perform its function (and cannot be replaced). gsmSRF sends UnavailableResource. 

precondition: SRSM state User Interaction 

postcondition: SRSM state User Interaction 

8.1.13 UnexpectedComponentSequence 

8.1 .1 3.1 General description 
8.1.13.1.1 Error description 

The responding entity cannot start the processing of the requested operation because a S ACF or MACF rule is violated, 
or the operation could not be processed in the current state of the receiving entity. 

8.1 .1 3.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging CalllnformationRequest 

FumishCharginglnformation RequestReportBCSMEvent 

ResetTimer SendCharginglnformation 

Call Associated/Call Processing 

Connect ConnectToResource 

Continue DisconnectForwardConnection 

EstablishTemporaryConnection 

In this case the gsmSSF detects the erroneous situation, sends the UnexpectedComponentSequence error and remains in 

the same state. 

8.1 .1 3.3 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 

ApplyChargingReport 

InitialDP 

In case the operation is sent by an "initiating" gsmSSF in the context of an existing relationship, the gsmSCF returns the 
error parameter. On receiving the error the gsmSSF moves to Idle. 
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8.1 .1 3.4 Operations SCF->SRF (only applicable for direct SCF-SRF case) 

PlayAnnouncement 
PromptAndCoUectUserlnformation 

In this case the SRF detects the erroneous situation, sends the UnexpectedComponentSequence error and remains in the 
same state. 

8.1 .1 3.5 Operations SRF->SCF 

AssistRequestlnstructions 

In this case an error occurs if the SRF has already an established relationship with the SCF and for some reason sends a 
AssistRequestlnstructions. The SCF detects the erroneous situation, informs SL and maintenance functions and returns 
the error parameter. On receiving the parameter the SRF moves to idle and releases the temporary connection. 

8.1.14 UnexpectedDataValue 

8.1.14.1 General description 
8.1.14.1.1 Error description 

The responding entity cannot complete the processing of the requested operation because a parameter has an unexpected 
data value. 

NOTE: This error does not overlap with "ParameterOutOfRange". 

8.1 .1 4.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging FurnishCharginglnformation 

RequestReportBCSMEvent ResetTimer 

Call Associated/Call Processing 

Connect ConnectToResource 

EstablishTemporaryConnection 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 4.3 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 

ApplyChargingReport 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .14.4 Operations gsmSCF->gsmSRF 

PlayAnnouncement 
PromptAndCoUectUserlnformation 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 4.5 Operations SRF->SCF 

AssistRequestlnstructions 

Refer to subclause8.1.7 for the appropriate error procedures. 
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8.1.15 UnexpectedParameter 

8.1 .1 5.1 General description 
8.1.15.1.1 Error description 

There is an error in the received operation argument. A vaHd but unexpected parameter was present in the operation 
argument. The presence of this parameter is not consistent with the presence of the other parameters. The responding 
entity cannot start to process the operation. 

8.1 .1 5.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

ApplyCharging CalllnformationRequest 

FumishCharginglnformation RequestReportBCSMEvent 

ResetTimer SendCharginglnformation 

Call Associated/Call Processing 

Connect ConnectToResource 

EstablishTemporaryConnection 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 5.3 Operations gsmSSF->gsmSCF 

AssistRequestlnstructions 

ApplyChargingReport 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 5.4 Operations gsmSCF->gsmSRF 

Play Announcement 
PromptAndCollectUserlnformation 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 5.5 Operations SRF->SCF 

AssistRequestlnstructions 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.16 UnknownLegID 

8.1 .1 6.1 General description 
8.1.16.1.1 Error description 

This error is used to indicate to the gsmSCF that a specific leg, indicated by the LegID parameter value in the operation, 
is unknown to the gsmSSF. 

8.1 .1 6.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

SendCharginglnformation 
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Refer to subclause 8.1.7 for the appropriate error procedures. 



8.2 Entity related error procedures 



The following subclauses define the error handling for the entity related errors. Since the error situations are not 
originated by the reception of an operation, the invoking entity is denoted here as the entity at which the error situation 
is detected. The responding entity is the entity which receives the error report. 

The TCAP services used for reporting errors are described in Clause 10. 

8.2.1 Expiration of TgsF 

8.2.1.1 General description 
8.2.1.1.1 Error description 

A timeout occurred in the gsmSSF on the response from the gsmSCF. 

8.2.1 .2 Procedures gsmSSF->gsmSCF 

Procedure at the invoking entity (gsmSSF) 
Timeout occurs in gsmSSF on T^gp 

precondition: gsmSSF state Waiting for instructions 

or gsmSSF state Waiting for end of User Interaction 

or gsmSSF state Waiting for end of Temporary Connection 

postcondition: gsmSSF state Idle 

The gsmSSF aborts the dialogue and moves to the Idle state, the GMSC/VMSC handles the call according to the Default 
Call Handling parameter of the valid CSI. 

8.2.2 Expiration of Tsrf 

8.2.2.1 General description 
8.2.2.1.1 Error description 

A timeout occurred in the SRF on the response from the SCF. The procedures for handling this error are described in 
ETS 300 374-1, [14]. 

8.2.2.2 Procedures description 

The procedures for handling this error are described in ETS 300 374-1, [14]. 



Detailed operation procedures 



The gsmSSF states which are referred to in this section are described in GSM 03.78 [16]. The operations 

Play Announcement, PromptAndCollectUserlnformation and SpecialisedResourceReport refer to states in the gsmSRF, 

which are described in ETS 300 374-1 [14], Subclause 7.3.4. The gsmSRF control procedures are defined in 

ETS 300 374-1 [14], Subclause 7.3.5. Note that: 

the Handoff case is not supported, 

the support for voice recognition is optional, 

the support for speech synthesis from text is optional. 
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for the cases of direct IP connection to the SCF and all assist cases only the procedures at the initiating gsmSSF 
(together with relevant operation syntax and procedures) are specified in CAP. 

9.1 Spare 

9.2 ActivityTest procedure 

9.2.1 General description 

This operation is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF. If the 
relationship is still in existence, then the gsmSSF will respond. If no reply is received, then the gsmSCF will assume that 
the gsmSSF has failed in some way and will take the appropriate action. 

9.2.1.1 Parameters 

None. 

9.2.2 Spare 

9.2.3 Responding entity (gsmSSF) 

9.2.3.1 Normal procedure 

gsmSSF precondition: 

(1) A relationship exists between the gsmSCF and the gsmSSF. 

gsmSSF postconditions: 

(1) The SSME FSM stays in, or moves to the state "Non-call Associated Treatment". 

(2) If the dialogue ID is active and if there is a gsmSSF using the dialogue, the SSME sends a return result 
"ActivityTest" to the gsmSCF. If there are no other management activities, the SSME FSM returns to the state 
"Idle Management", or 

If the dialogue ID is not active, the TCAP in the gsmSSF will issue a P-Abort, the SSME will in that case never 
receive the ActivityTest operation and thus will not be able to reply. 

9.2.3.2 Error handling 

Not applicable. 

9.3 ApplyCharging procedure 
9.3.1 General description 

This operation is used for interacting from the gsmSCF with the gsmSSF function: CSE control of call duration. The 
ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF. 

The charging scenarios supported by this operation are those given in GSM 02.78 for CSE control of call duration. 

9.3.1.1 Parameters 

aChBillingChargingCharacteristics: 

This parameter specifies a list of parameters required for CSE control of call duration: 
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The list may contain: 

timeDurationCharging : 

This list contains the following parameters: 

maxCallPeriodDuration: 

This parameter specifies the period of time for which a call can progress before an ApplyChargingReport 
shall be sent to the gsmSCF. 

- releaselfdurationExceeded: 

This parameter specifies the action to be taken at the gsmSSF when the duration specified above has been 
reached. If the parameter is present, then the call is released. 

- Tone 

If the parameter is present, then a warning tone is played before the call is released. 

tariffSwitchlnterval: 

This parameter indicates to the gsmSSF the time duration until the next tariff switch. The measurement of the 
elapsed tariff switch period commences commences immediately upon successful execution of this operation. 

sendCalculationToSCPIndication: 

This parameter indicates that ApplyChargingReport operations (at least one at the end of the connection 
configuration charging process) are expected from the gsmSSF. This parameter is always set to TRUE. 

- party ToCharge: 

This parameter indicates a party in the call. 

9.3.2 Spare 

9.3.3 Responding entity (gsmSSF) 
9.3.3.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSSFand the gsmSCF. 

(2) The gsmSSF is in one of the following states: 
"Waiting for Instructions"; or 

"Waiting for End of User Interaction"; or 

"Waiting for End of Temporary Connection"; or 

"Monitoring" 

SSF postcondition: 

(1) No gsmSSF state transition 

On receipt of this operation, the gsmSSF sets the charging data using the information elements included in the operation. 

The gsmSSF will start monitoring for the Answer event upon receipt of the ApplyCharging operation if Answer has not 
already been received on an outgoing connection to a Called Party, a Temporary Connection or a connection to a 
gsmSRF. Upon subsequent detection of the Answer event on the outgoing connection charging is started. If the Answer 
event has been received from an outgoing connection already when the ApplyCharging operation is received then 
charging starts immediately. 
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Upon release of an outgoing conection to the Called Party, the Temporary Connection or the gsmSRF connection any 
indication of Answer event receipt on the outgoing connection is cleared i.e. set to Answer event not received. 

9.3.3.2 Error handling 

MissingParameter: This error is indicated if the "sendCalculationToSCPIndication" is not provided. 
UnexpectedDataValue: This error is indicated if the "sendCalculationToSCPIndication" is set to FALSE. 
TaskRefused: In addition to the generic error handling noted below, this error shall be indicated when: 

a previously received call period duration is pending, 

a tariffSwitchlnterval is indicated when a previously received tariffSwitchlnterval is pending. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services used for reporting 
operation errors are described in Clause 10. 

9.4 ApplyChargingReport procedure 
9.4.1 General description 

This operation is used by the gsmSSF to report charging related information to the gsmSCF as requested by the gsmSCF 
using the ApplyCharging operation. A report shall be made either when a call disconnection event is detected by the 
gsmSSF or when the gsmSSF detects that the call period duration indicated in parameter maxCallPeriodDuration 
(received in ApplyCharging operation) has been reached. 

9.4.1.1 Parameters 

- CallResult: 

This parameter provides the SCF with the charging related information previously requested using the 
ApplyCharging operation with its "sendCalculationToSCPIndication" parameter set to TRUE. The "CallResult" 
is a list, and can contain the following parameters: 

timeDurationChargingResult 

This is a list, and can contain the following parameters: 

timelnformation 

This is a choice of the following parameters: 

- timelfNoTariffSwitch 

This parameter will be present if no tariff switch has ocurred since the detection of Answer for the 
connection to the Called Party, Temporary Connection or SRF connection, otherwise it will be absent. 
If present, then the elapsed time since detection of Answer is reported. 

timelfTariffSwitch 

This parameter will be present if a tariff switch has ocurred since the detection of Answer for the 
connection to the Called Party, Temporary Connection or SRF connection, otherwise it will be absent. 
If present, then the parameter may contain the following information: 

timeSinceLastTariffSwitch 

The elapsed time since detection of the last tariff switch is reported. 

tariffSwitchlnterval 

This parameter is present only if a tariff switch was detected for the connection to the Called Party, 

the temporary connection or the gsmSRF connection in the reported call period. 

If present the time interval between either the detection of the Answer event or the previous 

tariff switch (whichever of these events was last detected) and the last tariff switch is reported. 

- party ToCharge 
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The "party ToCharge" parameter as received in the related ApplyCharging operation or deduced from the 
default value,to correlate the result to the request. 

- CallActive 

This parameter indicates whether the call is still active or has been released. 

9.4.2 Invoking entity (gsmSSF) 

9.4.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A relationship exists between the gsmSSF and the gsmSCF. 

(2) A charging event has been detected that was requested by the gsmSCF via an ApplyCharging operation or a 
Called Party, Temporary Connection or SRF disconnection event has occured. 

gsmSSF postconditions: 

(1) If release of the call has occurred because the allowed call duration has been reached: 

All outstanding EDPs shall be disarmed, 

ApplyChargingReport shall be sent to gsmSCF followed by any outstanding CalllnformationReports, 
if applicable. 

The gsmSSF shall transit to the 'Idle' state 

(2) If release of the call has occurred but not because the allowed call duration has been reached: 

If there are any outstanding EDPs or other reports then the gsmSSF shall remain in the same state, else 
The gsmSSF shall transit to the 'Idle' state 

This operation is invoked if a charging event has been detected that was requested by the gsmSCF. 

9.4.2.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services used for reporting 
operation errors are described in Clause 10. 

9.4.3 Spare 

9.5 AsslstRequestlnstructions procedure 
9.5.1 General description 

This operation is sent to the gsmSCF as requested by the gsmSSF, which is acting as the assisting gsmSSF in an assist 
procedure, or by an gsmSRF. The operation is sent when an assisting gsmSSF or an gsmSRF receives an indication from 
an initiating gsmSSF indicting an assist procedure. 

9.5.1.1 Parameters 

correlationID: 
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This parameter is used by the gsmSCF to associate the dialogue created from the assisting gsmSSF (or the 
gsmSRF) to the gsmSCF with the InitialDP from the gsmSSF. The value of the "correlationID" may be extracted 
from the digits received from the initiating gsmSSF. 

- iPSSPCapabilities: 

Indicates which gsmSRF resources are attached, available and supported within: 
- the VMSC/GMSC where the gsmSSF resides, or 
the IP where the gsmSRF resides. 

9.5.2 Invoking entity (gsmSSF/gsmSRF) 

9.5.2.1 Normal procedure 

gsmSSF preconditions: 

1) An assist indication has been detected by the assisting gsmSSF. 
gsmSSF postconditions: 

2) The assisting gsmSSF is in state 'Waiting For Instruction'. 

On receipt of an assist indication from the initiating gsmSSF, the gsmSSF or gsmSRF shall ensure that there are suficient 
resources available to invoke an AssistRequestlnstructions operation in the gsmSSF/gsmSRF, and to indicate to the 
initiating gsmSSF that the call is accepted. The AssistRequestlnstructions operation is invoked by the gsmSSF or 
gsmSRF after the call (which is initiated by the assist indication) is accepted. 

9.5.2.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services used for reporting 
operation errors are described in Clause 10. 

9.5.3 Spare 

9.6 Spare 

9.7 CalllnformationReport procedure 
9.7.1 General description 

This operation is used to send specific call information for a single call to the gsmSCF as requested by the gsmSCF in a 
previous CalllnformationRequest operation. 

9.7.1.1 Parameters 

- requestedlnformationList: 

According to the requested information the gsmSSF sends the appropriate types and values to the gmSCF. 

- leglD: 

This parameter indicates the party in the call for which the information has been collected. When absent, it 
indicates the 'outgoing' leg created with Connect or Continue. 
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9.7.2 Invoking entity (gsmSSF) 

9.7.2.1 Normal procedure 

gsmSSF preconditions: 

1) At least one party disconnects from a call. 

2) Requested call information has been collected. 

3) CalllnformationReport is pending due to a previously received CalllnformationRequest operation. 

4) A relationship exists between the gsmSSF and the gsmSCF. 

gsmSSF postcondition: 

1) The gsmSSF shall move to the "Idle" state in the case where no other report requests are pending and no EDPs 
are armed otherwise the gsmSSF shall remain in the same state. 

If the gsmSSF executes a state transition caused by one of the following events: 

Calling party release; 

Calling party abandon; 

Called party release; 

Called party busy; 

gsmSSF no answer timer expiration; 

- route select failure indicated by the network; 

- release call initiated by the gsmSCF, 

and a CalllnformationRequest is pending then the CalllnformationReport operation is sent to the gsmSCF. 

If a CalllnformationReport has been sent to the gsmSCF then no CalllnformationReport is pending, i.e. a further 
CalllnformationReport, e.g. in the case of follow-on, has to be explicitly requested by the gsmSCF. 

If the event causing the CalllnformationReport is also detected by an armed EDP-R then immediately after 
CalllnformationReport the corresponding EventReportBCSM has to be sent. 

If the event causing the CalllnformationReport is also detected by an armed EDP-N then immediately before 
CalllnformationReport the corresponding EventReportBCSM has to be sent. 

9.7.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.7.3 Spare 

9.8 CalllnformationRequest procedure 



9.8.1 General description 



This operation is used to request the gsmSSF to record specific information about a single call and report it to the 
gsmSCF using the CalllnformationReport operation. 
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9.8.1.1 Parameters 

- requestedlnformationTypeList: 

This parameter specifies a list of specific items of information which is requested. 

The list may contain: 

callAttemptElapsedTime: 

This parameter indicates the duration between the end of CAP processing of operations initiating call setup 
("Connect" or "Continue") and the received answer indication from the called party side. In case of 
unsuccessful call setup the network event indicating the unsuccessful call setup stops the measurement of 
"callAttemptElapsedTime". 

- callStopTime: 

This parameter indicates the time stamp when the connection is released. 

callConnectedElapsedTime: 

This parameter indicates the duration between the received answer indication from the called party side and 
the release of the connection. 

- releaseCause: 

This parameter indicates the release cause for the call. 

- leglD: 

This parameter indicates the party in the call for which information shall be collected. When absent, it indicates 
the 'outgoing' leg created with Connect or Continue. 

Any set of these values can be requested. 

9.8.2 Spare 

9.8.3 Responding entity (gsmSSF) 
9.8.3.1 Normal procedure 

gsmSSF preconditions: 

(1) Call origination attempt has been initiated. 

(2) A control relationship exists between gsmSSF and gsmSCF. 

The gsmSSF may receive the CalllnformationRequest operation within an existing call associated (CA) dialogue only. 

The CalllnformationRequest operation is accepted by the gsmSSF only in the state "Waiting for Instructions". The 
operation does not lead to any transition to another state. 

gsmSSF postconditions: 

1) Requested call information is retained by the gsmSSF. 

2) The gsmSSF is waiting for further instructions. 

The gsmSSF allocates a record and stores the requested information if already available and prepares the recording of 
information items that will become available later, e.g. "callStopTimeValue". 
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9.8.3.2 Error handling 

In any other than the "Waiting for Instruction" state the CalllnformationRequest operation will be handled as "out of 
context". 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.9 Cancel procedure 

9.9.1 General description 

The gmSCF uses this class 2 operation to request the gsmSRF to cancel a correlated previous operation. 

The operation to be deleted can be either a Play Announcement operation or a PromptAndCollect Userlnformation 
operation. 

The cancellation of an operation is indicated via a respective error indication, "Cancelled", to the invoking entity of the 
cancelled Play Announcement or PromptAndCollectUserlnformation operation. 

The Cancel operation can also be used to cancel all outstanding requests and enable the state machines 
(gsmSSF/gsmSRF) to go to "Idle". In this case the Cancel operation does not specify any specific operation to be 
cancelled. 

9.9.1.1 Parameters 

invokelD: 

This parameter specifies which operation is to be cancelled. 

allRequests: 

This parameter indicates that all active requests for EventReportBCSM, ApplyChargingReport and 
CalllnformationReport shall be cancelled. 

9.9.2 Spare 

9.9.3 Responding entity (gsmSRF) 

9.9.3.1 Normal procedure 

gsmSRF precondition: 

1) A PA/P&C has been received and the gsmSRF is in the "User Interaction" state. 

gsmSRF postcondition: 

1) The execution of the PA/P&C has been aborted and the gsmSRF remains in the "User Interaction" state. 

9.9.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 



ETSI 



GSM 09.78 version 6.1 .0 Release 1 997 68 TS 1 01 046 V6.1 .0 (1 998-08) 

9.9.4 Responding entity (gsmSSF) 

9.9.4.1 Normal procedure 

gsmSSF precondition: 

1) The gmSSF is in the states "Waiting for Instructions" or "Monitoring". 

gsmSSF postcondition: 

1) All active request for reports and notifications have been cancelled. 

2) In case the gsmSSF was in state "Monitoring" it shall return to idle; or 

In case the gsmSSF was in state "Waiting for Instructions" it will remain in that state. A subsequent call- 
processing operation will move the gsmSSF to state "Idle". 

The call, if in active state, is further treated by gsmSSF autonomously as a normal (non-IN) call. 

All resources allocated to the dialogue are released. 

9.9.4.2 Error handling 

Sending of return error on cancel is not applicable in the cancel "allRequests" case. 

9.10 Spare 

9.1 1 Connect procedure 
9.1 1 .1 General description 

This operation is used to request the gsmSSF to perform the call processing actions to route a call to a specific 
destination or to influence other call set-up information, e.g. the Generic Number. 

9.11.1.1 Parameters 

de stinationRouting Addres s : 

This parameter contains the called party number towards which the call is to be routed. 

alertingPattern: 

This parameter indicates the type of alerting to be applied. It is defined in GSM 09.02. 

- callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD : 

This parameter carries the dialled digits if the call is forwarded by the gsmSCF. 

- redirectingPartylD: 

This parameter indicates the directory number the call was redirected from. 

- redirectionlnformation: 

This parameter contains forwarding related information, such as redirecting counter. 
genericNumbers: 
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This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for 
transfer of Additional Calling Party Number. 

suppressionOf Announcement: 

This parameter indicates that announcements and tones which are played in the GMSC or the VMSC at non- 
successful call set-up attempts shall be suppressed. 

- oCSIAppHcable: 

This parameter indicates to the GMSC/gsmSSF that the Originating CAMEL Subscription Information, if 
present, shall be applied on the outgoing call leg created with the Connect operation. For the use of this 
parameter see GSM 03.78 [16]. 

9.11.2 Spare 

9.1 1 .3 Responding entity (gsmSSF) 

9.1 1 .3.1 Normal procedure 

gsmSSF preconditions: 

1) Mobile originating or terminating call attempt has been initiated. 

2) Basic call processing has been suspended at a DP. 

3) The gsmSSF waits for instructions. 
gsmSSF postcondition: 

1) The gsmSSF performs the call processing actions to route the call to the specified destination. 

On receipt of this operation in the gsmSSF state "Waiting for Instructions", the gsmSSF performs the following actions: 

the gsmSSF cancels T^gp; 

if the "callingPartyNumber" is supplied, this value may be used for all subsequent gsmSSF processing; 

if no EDPs have been armed and no CalllnformationReport or ApplyChargingReport has been requested the 
gsmSSF goes to state "Idle". Otherwise, the gsmSSF goes to state "Monitoring". 

No implicit activation or deactivation of DPs occurs. 

Statistic counter(s) are not affected. 

9.11.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.12 ConnectToResource procedure 



9.12.1 General description 



This operation is used to connect a call from the gsmSSF to a specialized resource. After successful connection to the 
gsmSRF, the interaction with the caller can take place. The gsmSSF relays all operations for the gsmSRF and all 
responses from the gsmSRF. 
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9.12.1.1 Parameters 

- resourceAddress: 

This parameter identifies the physical location of the gsmSRF. 

iPRoutingAddress: 

This parameter indicates the routing address to set up a connection towards the gsmSRF. 

none: 

This parameter indicates that the call party is to be connected to a predefined gsmSRF. 

servicelnteractionlndicatorsTwo: 

This parameter contains an indicator sent from the gsmSCF to the gsmSSF, for control of the through connection 
to the Calling Party from the gsmSRF. Note that the Assisting gsmSSF shall always assume that Bothway 
Throughconnection is required, and hence will ignore this parameter if received. 

9.12.3 Responding entity (gsmSSF) 

9.12.3.1 Normal procedure 

gsmSSF preconditions: 

1) BCSM: Call processing has been suspended at a DP and a control relationship has been established. 

2) The gsmSSF is in state "Waiting for Instructions". 
gsmSSF postconditions: 

1) The call is switched to the gsmSRF. 

2) A control relationship to the gsmSRF is established. 

3) The gsmSSF moves to the state "Waiting for End of User Interaction". T^^p is set. 

NOTE: The successful connection to the gsmSRF causes a state transition in the gsmSRF from "Idle" to 
"Connected". 

9.12.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.13 Continue procedure 
9.13.1 General description 

This operation is used to request the gsmSSF to proceed with call processing at the DP at which it previously suspended 
call processing to await gsmSCF instructions. The gsmSSF continues call processing without substituting new data from 
the gsmSCF. 

9.13.1.1 Parameters 

None. 
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9.13.2 Spare 

9.13.3 Responding entity (gsmSSF) 

9.13.3.1 Normal procedure 

gsmSSF preconditions 

1) BCSM: Basic call processing has been suspended at any DP. 

2) gsmSSF is in the state "Waiting for Instructions". 
gsmSSF postconditions 

1) BCSM: Basic call processing continues. 

2) gsmSSF is in the state "Monitoring", because at least one EDP was armed, or a CalllnformationReport or 
ApplyChargingReport was requested;or gsmSSF is in the state "Idle", because no EDPs were armed and neither a 
CalllnformationReport or an ApplyChargingReport was requested. 

The gsmSSF is in state "Waiting for instructions". The gsmSSF transits to state "Idle" in case no EDPs are armed and no 
outstanding report requests are present. The gsmSSF transits to state "Monitoring" if at least one EDP is armed, or if 
there is at least one outstanding report request. Basic call processing is resumed. 

9.13.3.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.14 DisconnectForwardConnection procedure 

9.14.1 General description 

This operation is used in the following two cases: 

a) To clear a connection to an gsmSRF: 

this operation is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a 
ConnectToResource operation. It is used for a forward disconnection from the gsmSSF. An alternative solution is 
the backward disconnect from the gsmSRF, controlled by the "DisconnectFromlPForbidden" parameter in the 
Play Announcement and PromptAndCoUectUserlnformation operations; 

b) To clear a connection to an assisting SSF: 

this operation is sent to the non-assisting gsmSSF involved in an assist procedure. It is used to disconnect the 
temporary connection between the gsmSSF and the assisting SSF, and the assisting SSF and its associated 
gsmSRF. 

9.14.1.1 Parameters 

None. 

9.14.2 Spare 

9.14.3 Responding entity (gsmSSF) 
9.14.3.1 Normal procedure 

gsmSSF preconditions: 
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1) Call origination attempt has been initiated. 

2) Basic call processing has been suspended at a DP. 

3) The gsmSSF is in the state "Waiting for End of User Interaction" or "Waiting for End of Temporary 
Connection". 

gsmSSF postconditions: 

1) The connection to the gsmSRF or assisting SSF is released. 

2) The gsmSSF is waiting for instructions. 

The receipt of DisconnectForwardConnection results in disconnecting the assisting SSF or the PE containing the 
gsmSRF from the concerned call. It does not release the connection from the gsmSSF back to the end user. 

This operation is accepted in the gsmSSF states "Waiting for End of Temporary Connection" or "Waiting for End of 
User Interaction". On receipt of this operation in these states, the gsmSSF shall perform the following actions: 

- release the connection to the assisting SSF or the relay gsmSRF; 
the gsmSSF resets timer T^gp; 

the gsmSSF goes to state "Waiting for Instructions". 

The DisconnectForwardConnection operation contains no parameters. 

NOTE: The successful disconnection to the gsmSRF causes a state transition in the gsmSRF to "Idle". A current 
order (Play Announcement or PromptAndCollectUserlnformation) is cancelled and any queued order is 
discarded. 

9.14.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.15 EstablishTemporaryConnection procedure 
9.15.1 General description 

This operation is used to create a connection between a gsmSSF and an assisting SSF as part of a service assist 
procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF, for the case where the gsmSRF 
exists in a separately addressable PE (an IP). 

Note that assistingSSPIPRoutingAddress should contain routing digits, a correlationID and an scfID when a temporary 
connection is to be established between PLMNs and no bilateral agreement exists between the involved network 
operators to transfer correlationID and SCFiD as separate parameters. 

9.15.1.1 Parameters 

- assistingSSPIPRoutingAddress: 

This parameter indicates the destination address of the gsmSRF or assisting gsmSSF for assist procedure. The 
"assistingSSPIPRoutingAddress" may contain embedded within it, a "correlationID" and "scfID", but only if 
"correlationID" and "scfID" are not specified separately. 

correlationID: 

This parameter is used by the gsmSCF to associate the dialogue created from the assisting SSF (or the gsmSRF) 
to the gsmSCF with the InitialDP from the gsmSSF. The "correlationID" is used only if the correlation ID is not 
embedded in the "assistingSSPIPRoutingAddress". The network operators have to decide about the actual 
mapping of this parameter on the signalling system. 



ETSI 



GSM 09.78 version 6.1 .0 Release 1 997 73 TS 1 01 046 V6.1 .0 (1 998-08) 

- scflD: 

This parameter indicates the gsmSCF identifier and enables the assisting SSF to identify which gsmSCF the 
AssistRequestlnstructions should be sent to. The "scflD" is used only if the SCF ID is not embedded in the 
"assistingSSPIPRoutingAddress". The network operators have to decide about the actual mapping of this 
parameter on the signalling system. 

servicelnteractionlndicatorsTwo: 

This parameter contains an indicator sent from the gsmSCF to the gsmSSF for control of the through connection 
to the Calhng Party. 

9.15.2 Spare 

9.15.3 Responding entity (gsmSSF) 

9.15.3.1 Normal procedure 

gsmSSF preconditions: 

1) Call origination attempt has been initiated. 

2) BCSM has been suspended at a DP. 

3) The gsmSSF waits for instructions. 
gsmSSF postconditions: 

1) The gsmSSF performs the call processing actions to route the call to the assisting SSP or IP. 

2) The gsmSSF waits for end of temporary connection. 

On receipt of this operation in the gsmSSF state "Waiting for Instructions", the gsmSSF has to perform the following 
actions: 

- reset the Tgsp to T^xc; 

- route the call to gsmSRF or assisting gsmSSF using "assistingSSPIPRoutingAddress"; 

9.15.3.2 Error handling 

Until the connection setup has been accepted by the assisting SSP/IP, all received failure indications from the network 
on the ETC establishment shall be reported to the gsmSCF as ETC error ETCFailed (e.g., busy, congestion). The 
operation timer for ETC shall be longer then the maximum allowed time for the signalling procedures to accept the 
connection. 

NOTE: The connection setup may fail if CorrelationID or SCFiD are not supported as separate ISUP parameters. 
The error ETCFailed will be returned if SCFiD or CorrelationID are not supported in the gsmSSF. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 
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9.16 Spare 

9.17 EventReportBCSM procedure 
9.17.1 General description 

This operation is used to notify the gsmSCF of a call related event previously requested by the gsmSCF in an 
RequestReportBCSMEvent operation. The monitoring of more than one event could be requested with a 
RequestReportBCSMEvent operation, but each of these requested events is reported in a separate EventReportBCSM 
operation. 

9.17.1.1 Parameters 

- eventTypeBCSM: 

This parameter specifies the type of event that is reported. 

eventSpecificInformationBCSM: 

This parameter indicates the call related information specific to the event. 

For RouteSelectFailure it will contain the "FailureCause", if available. 

For O- or T-Busy it will contain the "BusyCause", if available. 

For O- or T-NoAnswer it will be empty. 

For O- or T- Answer it will be empty. 

For O- or T-Disconnect it will contain the "releaseCause", if available. 

For O- and T-NotReachable it will contain the "releaseCause", if available. 

- leglD: 

This parameter indicates the party in the call for which the event is reported. gsmSSF will use the option 
"receivingSidelD" only. 

- receivingSidelD: 

If not included, the following defaults are assumed: 

"leglD" = 1 for the events O- Abandon and T- Abandon, 

"leglD" = 2 for the events RouteSelectFailure, O-CalledPartyBusy, O-NoAnswer, O- Answer, O- 
NotReachable, T-CalledPartyBusy, T-NoAnswer, T- Answer and T-NotReachable. 

The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 

miscCalllnfo: 

This parameter indicates DP related information. 

- message Type: 

This parameter indicates whether the message is a request, i.e. resulting from a RequestReportBCSMEvent 
with "monitorMode" = "interrupted", or a notification, i.e. resulting from a RequestReportBCSMEvent with 
"monitorMode" = "notify AndContinue". 



9.1 7.2 Invoking entity (gsmSSF) 
9.17.2.1 Normal procedure 

gsmSSF preconditions: 
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1) The gsmSSF shall be in the state "Monitoring"; or the gsmSSF may be in state "Waiting for Instructions" if the 
Disconnect DP is armed and encountered; or the gsmSSF may be in any state if the Abandon DP is armed and 
encountered. 

2) The BCSM proceeds to an EDP that is armed. 
gsmSSF postconditions: 

1) The gsmSSF stays in the state "Monitoring" if the message type was notification and there are still EDPs armed 
or a CalllnformationReport or ApplyChargingReport requested. 

2) The gsmSSF moves to the state "Idle" if the message type was notification and there are no more EDPs armed, or 
no CalllnformationReport or ApplyChargingReport is requested. 

3) The gsmSSF moves to the state "Waiting for Instructions" if the message type was request. Call processing is 
interrupted. 

If a EDP-R is met that causes the release of the related leg all EDPs related to that leg are disarmed and the event is 
reported via EventReportBCSM. 

9.17.2.2 Error handling 

In case the message type is request, on expiration of Tg^p before receiving any operation, the gsmSSF aborts the 
interaction with the gsmSCF and instructs the GMSC/MSC to handle the call according to the Default Call Handling 
parameter of the valid CSI. 

Operation related error handling is not applicable, due to class 4 operation. 

9.17.3 Spare 

9.18 FurnishCharginglnformation procedure 
9.18.1 General description 

This operation is used to send charge related information to a logical call record. This logical call record is CAMEL 
specific. The first FCI of a call leg leads to the generation of a logical call record. Receipt of subsequent FCIs on the 
same leg shall overwrite the contents of the logical call record. When additional FCIs are to be used an EDP-R shall be 
armed in order to be able to apply FCI before the termination of the call record generation. 

9.18.1.1 Parameters 

FCIBillingChargingCharacteristics: 

This parameter contains the following sub-parameters; 

- FCIBCCCAMELsequencel: 

This parameter contains the following sub-parameters; 

FreeFormatData 

This parameter indicates free-format billing and/or charging characteristics. 

Party ToCharge 

This parameter indicates the party to bill and/or charge. 
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9.18.2 Spare 

9.18.3 Responding entity (gsmSSF) 

9.18.3.1 Normal procedure 

gsmSSF preconditions: 

1) gsmSSF State "Waiting for Instructions" or 

gsmSSF State "Waiting for End of User Interaction" or 

gsmSSF State "Waiting for End of Temporary Connection" or 

gsmSSF state "Monitoring" 

gsmSSF postcondition: 

1) No FSM state transition. 

On receipt of this operation the SSF performs actions to create the call record if necessary, and writes the free-format 
information carried in the operation into the call record. Note that an FCI operation will create a Logical Call Data 
Record (CDR) if such a record does not already exist for the indicated leg. Subsequent FCI operations received for a 
given leg, before a disconnection event has been received from or propagated to that leg, will overwrite the data 
previously written in the free-format CDR field. 

The Logical CDRs will be associated for a given call into one or more physical CDRs, as specified in GSM 12.05. 

A logical CDR is output when a disconnection event is propagated to the Leg associated with it, or when a Connect 
operation to create a connection to a Follow-on Called Party is received. 

9.18.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.19 InitialDP procedure 
9.19.1 General description 

This operation is sent by the gsmSSF after detection of a TDP-R in the BCSM, to request the gsmSCF for instructions to 
complete the call. 

9.19.1.1 Parameters 

serviceKey: 

This parameter identifies for the gsmSCF unambiguously the requested IN service. It is used to address the 
correct application/SLP within the gsmSCF (not for gsmSCF addressing). 

calledPartyNumber: 

This parameter contains the number used to identify the called party in the forward direction, e.g. the Called 
party number of ISUP (see ETS 300 356-1 [4]). This parameter shall be sent only in the Mobile Terminating and 
Mobile Forwarding cases. 

callingPartyNumber: 

This parameter carries the calling party number to identify the calling party or the origin of the call. The 
encoding of the parameter is defined in ETS 300 356-1 [4]. 
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- callingPartysCategory: 

Indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD : 

This parameter carries the dialled digits if the call has met call forwarding on the route to the gsmSSF. 

locationNumber: 

This parameter is used to convey the geographical area address for mobility services. It is used when 
"callingPartyNumber" does not contain any information about the geographical location of the calling party (e.g., 
origin dependent routing when the calling party is a mobile subscriber). 

- bearerCapability: 

This parameter indicates the type of the bearer capability connection to the user: 

- bearerCap: 

This parameter contains the value of the ISUP User Service Information parameter. 

The parameter "bearerCapability" shall only be included in the InitialDP operation in case the ISUP User 
Service Information parameter is available at the gsmSSF. 

If User Service Information and User Service Information Prime are available at the gsmSSF the "bearerCap" 
shall contain the value of the User Service Information Prime parameter. 

- eventTypeBCSM: 

This parameter indicates the armed BCSM DP event, resulting in the InitialDP operation. 

- redirectingPartylD: 

This parameter indicates the directory number the call was redirected from. 

- redirectionlnformation: 

It contains forwarding related information, such as redirecting counter. 

- iPSSPCapabilities: 

Indicates which gsmSRF resources supported within the VMSC/GMSC the gsmSSF resides in are attached and 
available. 

additionalCallingPartyNumber: 

The calling party number provided by the access signalling system of the calling user. 

highlayerCompatibility: 

This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN- 
teleservice of a connected ISDN terminal. For encoding, DSSl (see ETS 300 403-1 [5]) is used. 

- iMSI: 

IMSI of the mobile subscriber for which the CAMEL service is invoked. For encoding see GSM 09.02 [15]. 

- subscriberState: 

The state of the mobile subscriber for which the CAMEL service is invoked. The possible states are busy, idle 
and not reachable. For encoding see GSM 09.02 [15]. 

locationlnformation: 

This parameter indicates the whereabouts of the MS, and the age of the information defining the whereabouts. 
For encoding see GSM 09.02 [15]. 
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- ext-BasicServiceCode: 

Indicates the Basic Service Code. For encoding see GSM 09.02 [15]. 

callReferenceNumber: 

This parameter gives the network call reference number assigned to the call by the GMSC/MSC. For encoding 
see GSM 09.02 [15]. 

mscAddress: 

This parameter gives the mscid assigned to the GMSC/MSC. For encoding see GSM 09.02 [15]. 

- calledPartyBCDNumber: 

This parameter contains the number used to identify the called party in the forward direction. It may also include 
service selection information, including * and # digits. This parameter shall be sent only in the MO case. 

time&Timezone : 

This parameter contains the time that the gsmSSF was triggered, and the time zone that the invoking gsmSSF resides 
in. 

gsm-ForwardingPending: 

This parameter indicates that a forwarded-to-number was received and the call will be forwarded due to GSM 
supplementary service call forwarding in the GMSC. 

9.1 9.2 Invoking entity (gsmSSF) 

9.19.2.1 Normal procedure 

gsmSSF preconditions: 

1) A Call attempt has been initiated. 

2) An event has been detected at a DP. 
gsmSSF postcondition: 

1) A control relationship has been established and the gsmSSF waits for instructions from the gsmSCF. 

The address of the gsmSCF the InitialDP operation shall be sent to is fetched from the valid CSl. The gsmSSF provides 
all available parameters. 

A control relationship is established to the gsmSCF. The gsmSSF application timer T^^p is set when the gsmSSF sends 
InitialDP for requesting instructions from the gsmSCF. It is used to prevent from excessive call suspension time. 

9.19.2.2 Error handling 

If the destination gsmSCF is not accessible then the gsmSSF instructs the GMSC/MSC to handle the call according to 
the Default Call Handling parameter of the valid CSl. 

On expiration of T^gp before receiving any operation, the gsmSSF aborts the interaction with the gsmSCF and instructs 
the GMSC/VMSC to handle the call according to the Default Call Handling parameter of the valid CSl. 

If the calling party abandons after the sending of InitialDP, then the gsmSSF aborts the control relationship after the first 
answer message from the gsmSCF has been received. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 
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9.19.3 Spare 

9.20 Spare 

9.21 PlayAnnouncement procedure 
9.21 .1 General description 

This operation is used for inband interaction with a GSM user. 

9.21.1.1 Parameters 

informationToS end: 

This parameter indicates an announcement, or a tone to be sent to the end user by the gsmSRF. 

inbandlnfo: 

This parameter specifies the inband information to be sent. 

- messagelD: 

This parameter indicates the message(s) to be sent, this can be one of the following: 

elementaryMes s agelD : 

This parameter indicates a single announcement. 

- text: 

This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) 
by the gsmSRF. The attributes of text may consist of items such as language. 

elementaryMessagelDs : 

This parameter specifies a sequence of announcements. 

- variableMessage: 

This specifies an announcement with one or more variable parts. 

numberOfRepetitions : 

This parameter indicates the maximum number of times the message shall be sent to the end-user. 

duration: 

This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. 

ZERO indicates endless repetition. 

- interval: 

This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of 
the announcement and the start of the next repetition. This parameter shall only be used when the number 
of repetitions is greater than one. 

tone: 

This parameter specifies a tone to be sent to the end-user. 

- tonelD: 

This parameter indicates the tone to be sent. 

duration: 

This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite 

duration. 

disconnectFromlPForbidden: 

This parameter indicates whether or not the gsmSRF shall be disconnected from the user when all information 

has been sent. 
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- requestAnnouncementComplete: 

This parameter indicates whether or not a SpecializedResourceReport shall be sent to the gsmSCF when all 
information has been sent. 

9.21.2 Spare 

9.21 .3 Responding entity (gsmSRF) 

9.21.3.1 Normal procedure 

gsmSRF precondition: 

1) The gsmSRF is in the state "Connected"; or in the state "User Interaction" if the gsmSRF received previously an 
operation from the gsmSCF. 

gsmSRF postconditions: 

1) The gsmSRF sends the information to the user as indicated by "informationToSend". 

2) The gsmSRF moves to the state "User Interaction"; or 
remains in the same state. 

3) If all information has been sent and "RequestAnnouncementComplete" was set TRUE, the gsmSRFsends a 
SpecializedResourceReport operation to the gsmSCF. 

4) If all information has been sent and "disconnectFromlPForbidden" was set FALSE, the gsmSRF disconnects 
from the user. 

The announcement sent to the end-user is ended in the following conditions: 

- if neither "duration" or "numberOfRepetitions" is specified, then the network specific announcement ending 
conditions shall apply; or 

if "numberOfRepetitions" is specified, when all repetitions have been sent; or 

if "duration" is specified, when the duration has expired. The announcement is repeated until this condition is 
met; or 

if "duration" and "numberOfRepetitions" is specified, when either condition is satisfied (whatever comes first). 

9.21.3.2 Error handling 

If a Cancel operation is received before or during the processing of the operation then the operation is immediately 
cancelled and the error "Cancelled" is reported to the gsmSCF. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.22 PromptAndCollectUserlnformation procedure 
9.22.1 General description 

This operation is used to interact with the calling party in order to collect information. 

9.22.1.1 Parameters 

coUectedlnfo: 
coUectedDigits: 
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minimumNbOfDigits : 

If this parameter is missing, the default value is defined to be 1 . The "minimumNbOfDigits" specifies the 
minimum number of valid digits to be collected. 

maximumNbOfDigits : 

This parameter shall always be present and specifies the maximum number of valid digits to be collected. 

The following applies: 

"maximumNbOfDigits" > "minimumNbOfDigits". 

endOfReplyDigit: 

This parameter indicates the digit(s) used to signal the end of input, and can be one or two digits. 

In case the "maximumNbOfDigits" > "minimumNbOfDigits" the following applies: 

If "endOfReplyDigit" is not present, the end of input is indicated: 

when the inter-digit timer expires; or 

when the number of valid digits received equals the "maximumNbOfDigits". 
If "endOfReplyDigit" is present, the end of input is indicated: 

when the inter-digit timer expires; or 

when the end of reply digit is received; or 

when the number of valid digits received equals the "maximumNbOfDigits". 

When the end of input is attained, the collected digits are sent from gsmSRF to the gsmSCF. In the case 
the number of valid digits received is less than the "minimumNbOfDigits" when the inter-digit timer 
expires or when the end of reply digit is received, the input is specified as being erroneous. 

cancelDigit: 

If this parameter is present, the cancel digit(s) can be entered by the user to request a possible retry. This 
parameter can be one or two digits. All digits already received by the gsmSRF are discarded and the same 
PromptAndCollectUserlnformation procedure is performed again, thus e.g. the same announcement to 
request user information is given to the user and information is collected. If this parameter is not present, 
the user is not able to request a possible retry. 

- startDigit: 

If this parameter is present, the start digit indicates the start of the valid digits to be collected. The digits 
that are received by the gsmSRF before this start digit is received, are discarded and are not considered to 
be valid. This parameter can be one or two digits. 

If this parameter is not present, all received digits are considered to be valid. 

When the end of input is attained, the collected digits are sent from gsmSRF to the gsmSCF, including the 
'startDigit' if received by the gsmSRF. 

firstDigitTimeOut: 

If this parameter is present, the first digit should be received by the gsmSRF before the first-digit timer 
expiration. If the first digit is not received before first-digit timer expiration, the input is regarded to be 
erroneous. After receipt of the first vahd or invalid input digit, the corresponding first-digit timer is 
stopped. 

If this parameter is not present, then the gsmSRF uses a default value for the first-digit timer. 

If "startDigit" is present, the first-digit timer is stopped after the start digit is received. 

interDigitTimeOut: 
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If this parameter is present any subsequent valid or invalid digit, should be received by the gsmSRF 
before the inter-digit timer expires. As a result the inter-digit timer is reset and restarted. 

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of 
received valid digits is less than the "minimumNbOfDigits", the input is regarded to be unsuccessful. 

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of 
received valid digits is greater than the "minimumNbOfDigits", and less than or equal to the 
"maximumNbOfDigits", the input is regarded to be successful. 

If the "interDigitTimeOut" is not present, then the gsmSRF uses a default value for the inter-digit timer. 

errorTreatment: 

This optional parameter defines what specific action should be taken by the gsmSRF in the event of error 
conditions occurring. The default value is stdErrorAndlnfo. 

- interruptableAnnInd: 

This parameter is optional, where the default value is TRUE. 

If this parameter is TRUE, the announcement is interrupted after the first valid or invalid digit is received 
by the gsmSRF. If the announcement is interrupted, a possible start-digit timer will not apply anymore. 
However, if the announcement has not been interrupted, a possible start-digit timer is started after the 
announcement has been finished. 

If this parameter is present and explicitly set to FALSE, the announcement will not be interrupted after the 
first digit is received by the gsmSRF. The received digits during the announcement are discarded and 
considered to be invalid. All other specified parameters ("minimumNbOfDigits", "maximumNbOfDigits", 
"endOfReplyDigit", etc.) do not apply before the announcement has been finished. The possible start-digit 
timer is started after the announcement has been finished. 

voicelnformation: 

This parameter is optional, where the default value is FALSE. If the "voicelnformation" parameter is 
FALSE, all valid or invalid digits are entered by DTMF. 

If this parameter is present and explicitly set to TRUE, the calling user is required to provide all valid or 
invalid information by speech. The gsmSRF will perform voice recognition and translation of the 
provided information into digits. A possible end of reply digit will also have to be provided by speech. 

voiceBack: 

This parameter is optional, where the default value is FALSE. If the "voiceBack" parameter is FALSE, no 
voice back information is given by the gsmSRF. 

If this parameter is present and explicitly set to TRUE, the valid input digits received by the gsmSRF will 
be announced back to the calling user immediately after the end of input is received. The invalid input 
digits will not be announced back to the calling user. A possible end of reply digit is not voiced back. 

disconnectFromlPForbidden: 

This parameter indicates whether the gsmSRF should initiate disconnection to the gsmSSF after the interaction 
has been completed. If the parameter is not present or set to TRUE, the gsmSRF shall not initiate disconnection. 

informationToS end: 

This parameter indicates an announcement or tone to be sent to the end user by the gsmSRF. 

inbandlnfo: 

This parameter specifies the inband information to be sent. 

messagelD: 

This parameter indicates the message(s) to be sent, this can be one of the following: 
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elementaryMess agelD : 

This parameter indicates a single announcement. 

- text: 

This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) 
by the gsmSRF. The attributes of text may consist of items such as language. 

elementaryMessagelDs : 

This parameter specifies a sequence of announcements. 

variableMessage: 

This parameter specifies an announcement with one or more variable parts. 
numberOfRepetitions: 
This parameter indicates the maximum number of times the message shall be sent to the end-user. 

- duration: 

This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. 
ZERO indicates endless repetition. 

- interval: 

This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of 
the announcement and the start of the next repetition. This parameter can only be used when the number 
of repetitions is greater than one. 

- tone: 

This parameter specifies a tone to be sent to the end-user. 

- tonelD: 

This parameter indicates the tone to be sent. 

- duration: 

This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite 
duration. 

digitsResponse: 

This parameter contains the information collected from the end-user. 

9.22.2 Spare 

9.22.3 Responding entity (gsmSRF) 
9.22.3.1 Normal procedure 

gsmSRF precondition: 

1) The gsmSRF is in the state "Connected", or in state "User Interaction" if the gsmSRF received previously an 
operation from the gsmSCF. 

gsmSRF postconditions: 

1) The gsmSRF has sent the information to the end-user as indicated by "informationToSend". 
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2) The collected information from the end-user is sent to the gsmSCF as return result of the 
PromptAndCollectUserlnformation. 

3) If the "disconnectFromlPForbidden" was set to FALSE, the gsmSRF initiates a bearer channel disconnect to the 
gsmSSF and the gsmSRF moves to the state "Idle". 

4) Otherwise the gsmSRF moves to the state "User Interaction"; or remains in the same state. 

The announcement is sent to the end-user is ended in the following conditions: 

if neither "duration" or "numberOfRepetitions" is specified, then the network specific announcement ending 
conditions shall apply; or 

if "numberOfRepetitions" is specified, when all repetitions have been sent; or 

if "duration" is specified, when the duration has expired. The announcement is repeated until this condition is 
met; or 

if "duration" and "numberOfRepetitions" is specified, when either condition is satisfied (whatever comes first). 

The above conditions are overruled if the parameter "interruptableAnnInd" is not set to FALSE and the end-user has 
responded with a digit during the sending of the announcement. In this case the announcement is ended immediately. 

The parameter "errorTreatment" specifies how the gsmSRF shall treat the error "ImproperCallerResponse". The default 
value "stdErrorAndlnfo" means that the error shall be reported to gsmSCF as specified in Clause 8. The value "help" 
indicates that no error shall be reported to gsmSCF but assistance shall be given to the end-user in the form of a network 
dependent default announcement. The value "repeatPrompt" indicates that no error shall be reported to the gsmSCF but 
the prompt shall be repeated to the end-user. The last two procedures shall only be done once per PromptAndCollect- 
Userlnformation operation. 

The receipt of any 'endOflnput' condition (maximumNbOfDigits, endOfReplyDigit, cancelDigit, firstDigitTimeout, 
interDigitTimeout) terminates immediately the ongoing input. 

NOTE: In other words when e.g an endOfReplyDigit is received, the receipt of a subsequent cancelDigit will not 
be processed anymore. 

9.22.3.2 Error handling 

If a Cancel operation is received before or during the processing of the operation then the operation is immediately 
cancelled and the error "Cancelled" is reported to the invoking entity. 

Generic error handling for the operation related errors is described in Clause 8, the TCAP services which are used for 
reporting operation errors are described in Clause 10. 

9.23 ReleaseCall procedure 
9.23.1 General description 

This operation is used to tear down by the gsmSCF an existing call at any phase of the call for all parties involved in the 
call. The operation can only be sent within a control relationship and is not allowed in a monitor relationship. This 
operation shall not be sent to an assisting gsmSSF. 

9.23.1.1 Parameters 

Cause 

A number giving an indication to the gsmSSF about the reason of releasing this specific call. This may be used 
by gsmSSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release 

message. 
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9.23.2 Spare 

9.23.3 Responding entity (gsmSSF) 

9.23.3.1 Normal procedure 

gsmSSF preconditions: 

1) State "Waiting for Instructions"; or State "Monitoring". 

gsmSSF postcondition: 

1) "Idle", after sending any outstanding CalllnformationReport. Possible armed EDPs are ignored. All connections 
and resources related to the call are released. 

9.23.3.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.24 Spare 

9.25 RequestReportBCSMEvent procedure 
9.25.1 General description 

This operation is used to request the gsmSSF to monitor for a call-related event (e.g., BCSM events such as busy or no 
answer), then send a notification back to the gsmSCF when the event is detected. 

9.25.1.1 Parameters 

- bcsmEvents: 

This parameter specifies the event or events of which a report is requested. 

- eventTypeBCSM: 

This parameter specifies the type of event of which a report is requested. Values collectedlnfo and 
termAttemptAuthorized are not valid for the RequestReportBCSMEvent operation. 

monitorMode: 

This parameter indicates how the event should be reported. When the "monitorMode" is "interrupted", the 
event shall be reported as a request, if the "monitorMode" is "notify AndContinue", the event shall be reported 
as a notification, if the "monitorMode" is "transparent", the event shall not be reported. 

- leglD: 

This parameter indicates the party in the call for which the event shall be reported. gsmSCF will use the 
option "sendingSidelD" only. 

sendingSidelD: 

If not included, the following defaults are assumed for LegID: 

"leglD" = 1 for the events O- Abandon and T- Abandon, 

"leglD" = 2 for the events RouteSelectFailure, O-CalledPartyBusy, O-NoAnswer, O- Answer, O- 
NotReachable, T-CalledPartyBusy, T-NoAnswer, T- Answer and T-NotReachable. 
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The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 
dPSpecificCriteria: 
This parameter indicates information specific to the DP to be armed. 

applicationTimer: 

This parameter indicates the NoAnswer timer value for the NoAnswer event. If the user does 
not answer the call within the allotted time the gsmSSF reports the event to the gsmSCF. The timer shall be shorter than 
the network NoAnswer timer. 

9.25.2 Spare 

9.25.3 Responding entity (gsmSSF) 

9.25.3.1 Normal procedure 

gsmSSF precondition: 

1) A control relationship exists between the gsmSSF and the gsmSRF. 

2) The gsmSSF is in either the state "Waiting for Instructions" or the state "Monitoring". 

NOTE: In state "monitoring" only requests to disarm detection points (with MonitorMode set to "Transparent") or 
send notifications of events (with MonitorMode set to "Notify AndContinue") shall be accepted. 

gsmSSF postconditions: 

1) The requested EDPs have been armed as indicated. 

2) Previously requested events are monitored until ended by a transparent monitor mode, until the end of the call, 
until the EDPs are detected or until the corresponding leg is released. 

3) The gsmSSF remains in the same state, unless all EDPs have been disarmed and no CalllnformationReport or 
ApplyChargingReport has been requested; in the latter case the gsmSSF moves to the state "Idle". 

9.25.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.26 ResetTlmer procedure 
9.26.1 General description 

This class 2 operation is used by the gsmSCF to refresh the Tg^p application timer, in order to avoid the Tggp time-out 
at the gsmSSF. 

9.26.1.1 Parameters 

timerValue: 

This parameter specifies the value to which the T^^p timer is to be set. 

timerlD: 

This parameter has a default value identifying the Tggp timer. 
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9.26.2 Spare 

9.26.3 Responding entity (gsmSSF) 

9.26.3.1 Normal procedure 

gsmSSF preconditions: 

1) Call origination attempt has been initiated. 

2) Basic call processing has been suspended at a DP. 

3) The gsmSSF is in the "Waiting for Instruction" state or in the "Waiting for End of User Interaction" state or in 
the "Waiting for End of Temporary Connection" state. 

gsmSSF postconditions: 

1) The Tggp timer has been reset. 

2) The gsmSSF remains in the same state. 

9.26.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.27 SendCliarginglnformation procedure 
9.27.1 General description 

This operation is used to instruct the gsmSSF on the advice of charge information to be sent by the gsmSSF. The SCI 
operation may be invoked on multiple occasions. 

9.27.1.1 Parameters 

sCIBillingChargingCharacteristics: 

This parameter is a choice between two lists of information. 

The first list shall only be sent before an answer event has been detected from the current Called Party, 
Temporary Connection or connection to an SRF. It contains the following parameters: 

aOCBeforeAnswer: 

This is a list of the following information: 

- aOCInitial: 

This is a set of GSM Charge Advice Information elements, as defined in GSM 02.24 [26], and these CAI 
elements are sent by the gsmSSF to the MS when an ANSWER is received and a tariff switch has not yet 
occurred. 

aOCSubsequent: 

This list may indicate the following information: 

- CAIElements 

This is a set of GSM Charge Advice Information elements, as defined in GSM 02.24 [26], and these 
CAI elements are sent to the MS when Answer is detected and a tariff switch has occurred previously, 
or when Answer has previously been detected and a tariff switch occurs. 
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tariffSwitchlnterval: 

This parameter indicates to the gsmSSF the time duration until the next tariff switch. The measurement 
of the elapsed tariff switch period commences immediately upon successful execution of this 
operation. 

The second list in the Choice shall only be sent after an answer event has been detected from the current Called 
Party, Temporary Connection or connection to an SRF. It contains the following parameters: 

aOCAfterAnswer: 

This list may indicate the following information: 

cAIElements: 

This is a set of GSM Charge Advice Information elements, as defined in GSM 02.24 [26], and these CAI 
elements are sent to the MS by the gsmSSF when Answer is detected and a tariff switch has occurred 
previously, or when Answer has previously been detected and a tariff switch occurs in the call.. 

tariffSwitchlnterval: 

This parameter indicates to the gsmSSF the time duration until the next tariff switch. The measurement of 
the elapsed tariff switch period commences immediately upon successful execution of this operation. 

- leglD: 

This parameter indicates where the charging information shall be sent. 

9.27.2 Spare 

9.27.3 Responding entity (gsmSSF) 
9.27.3.1 Normal procedure 

gsmSSF preconditions: 

1) gsmSSF FSM State c: "Waiting for Instructions"; or 

gsmSSF FSM State d: "Waiting for End of User Interaction"; or 

gsmSSF FSM State e: "Waiting for End of Temporary Connection"; or 

gsmSSF FSM State f: "Monitoring". 

gsmSSF postcondition: 

1) No state transition. 

On receipt of this operation the gsmSSF performs actions to send the advice of charge information to the indicated Call 
Party s MS. 

If advice of charge is to be provided to a GSM MS in conjunction with CSE control of call duration then the following 
sequence of operations shall be sent from the gsmSCF to the gsmSSF in the following order, in the same TCAP TC- 
CONTINUE component; 

ApplyCharging; SendCharginglnformation 

These operations will be processed sequentially by the gsmSSF, in the order that they are sent by the gsmSCF. Note also 
that in this case parameter TariffSwitchlnterval may be present in either in the ApplyCharging operation or the 
SendCharginglnformation operation, but not in both operations. It is recommended that it shall be transported in the 
ApplyCharging operation. 

The TariffSwitchlnterval information received with either of these operations shall set the same tariff switch timer in the 
gsmSSF, and this duration timer shall run from the time of successful operation execution. 
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9.27.3.2 Error handling 

TaskRefused: In addition to the generic error handling noted below, this error shall be indicated when: 

a tariffSwitchlnterval is indicated when a previously received tariffSwitchlnterval is pending. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.28 Spare 

9.29 SpecializedResourceReport procedure 

9.29.1 General description 

This operation is used as the response to a Play Announcement operation when the announcement completed indication 
is set. 

9.29.1.1 Parameters 

None. 

9.29.2 Invoking entity (gsmSRF) 

9.29.2.1 Normal procedure 

gsmSRF preconditions: 

1) The gsmSRF is in the state "User Interaction". 

2) A Play Announcement operation is being executed for which the parameter "RequestAnnouncementComplete" 
was set TRUE. 

3) All information has been sent to the user. 
gsmSRF postconditions: 

1) The gsmSRF remains in the same state. 

2) If the "DisconnectFromlPForbidden" parameter was set FALSE, the SRSM initiates a bearer channel disconnect 
sequence to the gsmSSF using the applicable bearer channel signalling system after sending the 
SpecializedResourceReport operation to the gsmSCF. The gsmSRF moves to the state "Idle". 

9.29.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.29.3 Spare 



1 Services assumed from TCAP 
10.1 Normal procedures 

This subclause describes the procedures and TCAP primitives that shall be used for transmitting messages between 
gsmSSF and gsmSCF under normal operation. 
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The CAP, as TC-user, uses only the structured dialogue facility provided by TCAP. The following situations can occur 
when a message is sent between two physical entities: 

a dialogue shall be established: the TC-user issues a TC-BEGIN request primitive; 

a dialogue shall be maintained: the TC-user issues a TC-CONTINUE request primitive; 

a dialogue shall no longer be maintained: the TC-user issues a TC-END request primitive with either basic end or 
with pre-arranged end depending on the following conditions: 

- basic end: 

operations leading to a termination of the control relationship can be transmitted by the gsmSCF with a 
TC-END request primitive (basic) in case the gsmSCF is not interested in the reception of any ERROR or 
REJECT components for these sent operations; 

once the gsmSCF dialogue resources have been released any ERROR or REJECT components received 
for these sent operations will be discarded by TC as described in ETS 300 287 [3] 
(ITU-T Recommendation Q.774); 

if the gsmSCF entity has received an operation leading to the termination of the control relationship, a 
TC-END request primitive (basic) with zero components can be sent from the gsmSCF; 

if the gsmSSF has no pending operations or reports to process and no armed detection points which could 
be triggered, then a TC-END request primitive (basic) with zero components can be sent from the 
gsmSSF; 

- pre-arranged end: 

in case of an entity being interested in possible ERROR or REJECT messages in response to sent operations 
leading to a termination of the control relationship, the dialogue is ended with a TC-END request primitive 
(pre-arranged end) after the last associated operation timer expires. The receiving entity shall end the 
dialogue with a TC-END request primitive (basic or pre-arranged end) after successful processing of these 
operations (i.e. the control relationship is terminated); 

1 0.1 .1 gsmSSF-to-gsmSCF messages 

10.1.1.1 gsmSSF related messages 

A dialogue shall be established when the gsmSSF has finalised trigger processing and moves to the state Waiting for 
Instructions. The relevant CAP operation, which can only be the InitialDP operation, shall be transmitted in the same 
message. 

For all other operations sent from the gsmSSF, the dialogue shall be maintained. 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSSF. When the 
gsmSSF makes a state transition to the state Idle, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

When the gsmSSF has sent the last EventReportBCSM, ApplyChargingReport or CalllnformationReport the dialogue 
may be ended from the gsmSCF by a TC-END request primitive with basic end. 

10.1.1.2 Spare 

10.1.1.3 SSME FSM related messages 

The following procedures shall be followed: 

the dialogue shall be maintained when the Activity Test return result is sent; 
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1 0.1 .2 gsmSCF-to-gsmSSF messages 

1 0.1 .2.1 SCSM FSM related messages 

For subsequent operations sent from the SCSM FSM, the dialogue shall be maintained, i.e. all other operations are sent 
after a dialogue was established from the gsmSSF (the gsmSCF has previously received a TC-BEGIN indication 
primitive with an InitialDP operation). 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the 
gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and 
when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

Alternatively, the sending of operations, leading to the termination of the control relationship, by means of a TC-END 
request primitive (basic end) is possible. 

1 0.1 .2.2 SCME FSM related messages 

The operations sent from the SCME FSM shall be issued according to the following procedures: 
the dialogue shall be maintained when the Activity Test operation is sent; 

1 0.1 .3 gsmSCF-to/from-gsmSRF messages 

A dialogue is established when the gsmSRF sends an AssistRequestlnstructions operation to the gsmSCF. For all other 
operations sent from the SRF, the dialogue shall be maintained. 

The dialogue shall no longer be maintained when the prearranged end condition is met in both the gsmSRF and 
gsmSCF. When the gsmSRF makes a transition to the SRF FSM state Idle (see ETS 300 374-1, [14]), the dialogue is 
locally ended by means of a TC-END request primitive with prearranged end. 

When the gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations 
sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request 
primitive with prearranged end. 

Alternatively, the gsm SCF can send the last operation to the gsmSRF with a TC-END request primitive (basic end) 
when the gsmSCF does not expect any further messages and is no longer interested in any possible error and reject 
messages. 

In the relay case, the gsmSRF-gsmSCF relationship uses the gsmSSF-gsmSCF TCAP dialogue. This is possible, because 
begin and end of the gsmSRF-gsmSCF relationship are embedded in the gsmSSF-gsmSCF relationship. gsmSRF- 
gsmSCF information shall be exchanged with TC-CONTINUE request primitives. 



10.2 Abnormal procedures 



This subclause describes the procedures and TCAP primitives that shall be used for reporting abnormal situations 
between gsmSSF and gsmSCF. The error cases are defined in Clause 8. 

The following primitives shall be used to report abnormal situations: 

operation errors, as defined in the CAP, are reported with TC-U-ERROR request primitive; 

- rejection of a TCAP component by the TC-user shall be reported with TC-U-REJECT request primitive; 

a dialogue shall be aborted by the TC-user with a TC-U- ABORT request primitive. 

For abnormal situations detected by TCAP the same rules shall apply for transmission of TC-R-REJECT indication as 
for transmission of TC-U-REJECT request and for transmission of TC-P-ABORT indication as for transmission of 
TC-U-ABORT request primitive. 
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In error situations prearranged end shall not be used. In case any AE encounters an error situation the peer entity shall be 

explicitly notified of the error, if possible. If from any entity" s point of view the error encountered requires the 

relationship to be ended, it shall close the dialogue via a TC-END request primitive with basic end or via a 

TC-U- ABORT request primitive, depending on whether any pending ERROR or REJECT component is to be sent or 

not. 

In case an entity receives a TC-END indication primitive and after all components have been considered, the gsmSSF is 
not in a state to terminate the control relationship, an appropriate internal error should be provided. 

In cases when a dialogue needs to be closed by the initiating entity before its establishment has been completed (before 
the first TC indication primitive to the TC-BEGIN request primitive has been received from the responding entity), the 
TC-user shall issue a TC-END request primitive with prearranged end or a TC-U- ABORT request primitive. The result 
of these primitives will be only local, any subsequent TC indication received for this dialogue will be handled according 
to the abnormal procedures as specified in ETS 300 287 [3] (ITU-T Recommendation Q.774). 

1 0.2.1 gsmSCF-to-gsmSSF/relay gsmSRF messages 

Considering that both the gsmSSF and the gsmSRF do not have the logic to recover from error cases detected on the 
gsmSCF-gsmSSF/gsmSRF interface, the following shall apply: 

operation errors and rejection of TCAP components shall be transmitted to the gsmSSF (and relayed as necessary 
to the gsmSRF) respectively gsmSRF with a TC-END request primitive, basic end. 

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC-CONTINUE indication 
primitive, the gsmSSF respectively gsmSRF shall abort the dialogue with a TC-U- ABORT request primitive. 

10.2.2 gsmSSF/gsmSRF-to-gsmSCF messages 

Operation errors and rejection of TCAP components shall be transmitted to the gsmSCF according to the following 
rules: 

the dialogue shall be maintained when the preceding message, which contained the erroneous component, 
indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a TC-CONTINUE 
request primitive if the erroneous component was received with a TC-CONTINUE indication primitive; 

on receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either 
continue, explicitly end or abort the dialogue; 

If the error processing in the gsmSSF/gsmSRF leads to the case where the gsmSSF/gsmSRF is not able to process 
further gsmSCF operations while the dialogue is to be maintained, the gsmSSF/gsmSRF aborts the dialogue with a 
TC-U- ABORT request primitive. 

The gsmSSF aborts a dialogue with a TC-U- ABORT request primitive if call release is initiated by any other entity than 
the gsmSCF and the gsmSSF has no pending ApplyChargingRepoers or CalllnformationReports nor any armed EDPs to 
notify the gsmSCF of the call release. 



10.3 Dialogue establishment 



The establishment of an CAP dialogue involves two application processes as described in subclause 4.3, one that is the 
dialogue-initiator and one that is the dialogue-responder. 

AC negotiation may not be supported in all physical entities and/or all networks. 

This procedure is driven by the following signals: 

a TC-BEGIN request primitive from the dialogue-initiator; 

a TC-BEGIN indication primitive occurring at the responding side; 

the first TC-CONTINUE indication primitive occurring at the initiating side or under specific conditions: 
a TC-END indication primitive occurring at the initiating side; 



ETSI 



GSM 09.78 version 6.1 .0 Release 1 997 93 TS 1 01 046 V6.1 .0 (1 998-08) 

a TC-U-ABORT indication primitive occurring at the initiating side; 
a TC-P- ABORT indication primitive occurring at the initiating side. 

1 0.3.1 Sending of a TC-BEGIN request primitive 

Before issuing a TC-BEGIN request primitive, S ACF shall store the AC-name and if present the user-information 
parameter. 

SACF shall request the invocation of the associated operations using the TC -INVOKE service. See subclause 10.8 for a 
description of the invocation procedure. 

After processing of the last invocation request, SACF shall issue a TC-BEGIN request primitive. 

The requesting side SACF then waits for a TC indication primitive and will not issue any other requests, except a 
TC-U-ABORT request or a TC-END request with the release method parameter set to "pre-arranged release". 

1 0.3.2 Receipt of a TC-BEGIN indication 

On receipt of a TC-BEGIN indication primitive, SACF shall: 

analyze the application-context-name included in the primitive and if it is supported, process any other indication 
primitives received from TC as described in subclause 10.8. 

Once all the received primitives have been processed, SACF does not accept any primitive from TC, except a 
TC-P- ABORT indication. 

If the application-context-name included in the primitive is not supported, issue a TC-U-ABORT request primitive. If an 
alternative application-context can be offered its name is included in the TC-U-ABORT request primitive. 

NOTE: If the gsmSSF provides an AC which is not acceptable to the gsmSCF, then an alternate AC should not be 
returned. 

1 0.3.3 Receipt of tine first TC-CONTINUE indication 

On receipt of the first TC-CONTINUE indication primitive for a dialogue, SACF shall check the value of the 
application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive, SACF shall 
process the following TC component handling indication primitives as described in subclause 10.8, otherwise it shall 
issue a TC-U-ABORT request primitive. 



1 0.3.4 Receipt of a TC-END indication 



On receipt of a TC-END indication primitive in the dialogue initiated state, SACF shall check the value of the 
application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive then the 
SACF shall process the following TC component handling indication primitives as described in subclause 10.8, 
otherwise it shall not be processed. 

1 0.3.5 Receipt of a TC-U-ABORT indication 

Receipt of a TC-U-ABORT indication primitive is described as part of user abort procedure (see subclause 10.6.2). 

If the abort reason is application-context-name not supported, the responding side may propose an alternative 
application-context-name in the TC-U-ABORT indication. If an alternative application context is proposed the receiving 
entity shall check this name and if it can be supported a new dialogue may be established. 

NOTE: If an alternate application context is offered to the gsmSSF, it should not attempt to establish a new 
dialogue. 
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1 0.3.6 Receipt of a TC-P-ABORT indication 

Receipt of a TC-P-ABORT indication primitive is described as part of provider abort procedure (see subclause 10.7.1). 

10.4 Dialogue continuation 

Once established the dialogue is said to be in a continuation phase. 

Both application processes can request the transfer of CAP APDUs until one of them requests the termination of the 
dialogue. 

10.4.1 Sending entity 

SACF shall process any component handling request primitives as described in subclause 10.8. 

After processing the last component handling request primitive, SACF shall issue a TC-CONTINUE request primitive. 

10.4.2 Receiving entity 

On receipt of a TC-CONTINUE indication primitive SACF shall accept zero, one or several TC component handling 
indication primitives and process them as described in subclause 10.8. 



10.5 Dialogue ternnination 



Both the dialogue-initiator and the dialogue-responder have the ability to request the termination of a dialogue when no 
dialogue is to be established or when a dialogue is no longer to be maintained according to the rules as stated in 
subclauses 10.1 and 10.2. 

The dialogue termination procedure is driven by the following events: 

a TC-END request primitive; 

a TC-END indication primitive. 



1 0.5.1 Sending of TC-END request 



When the dialogue shall no longer be maintained, SACF shall process any component handling request primitives as 
described in subclause 10.8. 

After processing the last component handling request primitive (if any), SACF shall issue a TC-END request primitive 
with the release method parameter set to "basic end" or "pre-arranged release", according to the rules as stated in 
subclauses 10.1 and 10.2. 

When no dialogue is to be established, refer to subclauses 10.3.1 and 10.3.2. 

1 0.5.2 Receipt of a TC-END indication 

On receipt of a TC-END indication primitive, the SACF shall accept any component handling indication primitives and 
process them as described in subclause 10.8. 

After processing the last component handling primitive all dialogue related resources are released. 

10.6 User Abort 

Both the dialogue-initiator and the dialogue-responder have the ability to abort a dialogue at any time. 
The user abort procedure is driven by one of the following events: 
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a TC-U-ABORT request primitive; 
a TC-U-ABORT indication primitive. 

1 0.6.1 Sending of TC-U-ABORT request 

After issuing a TC-U-ABORT request primitive, all dialogue related resources are released. 

1 0.6.2 Receipt of a TC-U-ABORT indication 

On receipt of a TC-U-ABORT indication all dialogue related resources are released. 

10.7 Provider Abort 

TC has the ability to abort a dialogue at both the dialogue-initiator side and the dialogue-responder side. 
The provider abort procedure is driven by the following event: 
a TC-P- ABORT indication primitive. 

1 0.7.1 Receipt of a TC-P-ABORT indication 

On receipt of a TC-P-ABORT indication, all dialogue related resources are released. 

1 0.8 Procedures for CAP operations 

This subclause describes the procedures for CAP operations. 

10.8.1 Operation invocation 

SACF shall build an operation argument from the parameters received and request the invocation of the associated 
operation using the TC -INVOKE procedure. 

1 0.8.2 Operation invocation receipt 

On receipt of a TC-INVOKE indication primitive, SACF shall: 

if the invoke ID is already in use by an active operation, request the transfer of a reject component using the 
TC-U-REJECT request primitive with the appropriate problem code (duplicated invokelD); 

if the operation code does not correspond to an operation supported by the application-context, request the 
transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code 
(unrecognized operation); 

if the type of the argument is not the one defined for the operation, request the transfer of a reject component 
using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

if the operation cannot be invoked because the dialogue is about to be released, requests the transfer of a reject 
component using the TC-U-REJECT request primitive with the problem code (Initiating Release); 

if sufficient CAP related resources are not available to perform the requested operation, request the transfer of a 
reject component using the TC-U-REJECT request primitive with the problem code (Resource Limitation); 

otherwise, accept the TC-INVOKE indication primitive. If the operation is to be user confirmed, SACF waits for 
the corresponding response. 
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1 0.8.3 Operation response 

For user confirmed operations, SACF shall: 

if no error indication is included in the response to a class 1 or 3 operation, construct a result information element 
from the parameters received and request its transfer using the TC-RESULT-L service; 

if an error indication is included in the response to a class 1 or 2 operation, construct an error parameter from the 
parameters received and request its transfer using the TC-U-ERROR request primitive. 

1 0.8.4 Receipt of a response 

1 0.8.4.1 Receipt of TC-RESULT-NL indication 

On receipt of a TC-RESULT-NL indication, SACF shall: 

- request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate 
problem code (mistyped parameter). 

1 0.8.4.2 Receipt of TC-RESULT-L indication 

On receipt of a TC-RESULT-L indication, SACF shall: 

if the type of the result parameter is not the one defined for the result of this operation, request the transfer of a 
reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped 
parameter); 

otherwise, accept the TC-RESULT-L indication primitive. 

1 0.8.4.3 Receipt of TC-U-ERROR indication 

On receipt of a TC-U-ERROR indication, SACF shall: 

if the error code is not defined for the SACF or is not one associated with the operation referred to by the invoke 
identifier, request the transfer of a reject component using the TC-U-REJECT request primitive, with the 
appropriate problem code (unrecognized error or unexpected error); 

if the type of the error parameter is not the one defined for this error, request the transfer of a reject component 
using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

otherwise, accept the TC-U-ERROR indication primitive. 

1 0.8.4.4 Receipt of TC-U-REJECT indication 

On receipt of a TC-U-REJECT indication primitive which affects a pending operation, SACF shall accept the 
TC-U-REJECT indication primitive. 

1 0.8.4.5 Receipt of a TC-L-REJECT indication 

This event occurs when the local TC detects a protocol error in an incoming component which affects an operation. 

On receipt of a TC-L-REJECT indicating "return result problem, return result unexpected", SACF shall inform the 
application process. 

On receipt of a TC-L-REJECT indicating "return error problem, return error unexpected", SACF shall inform the 
application process. 

When the problem code indicates a general problem, it is considered that the event cannot be related to an active 
operation even if the invoke ID is provided by TC. This is because it is unclear whether the invoke ID refers to a local or 
remote invocation. The behaviour of SACF in such a case is described in subclause 10.8.5.3. 
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1 0.8.4.6 Receipt of a TC-L-CANCEL indication 

On receipt of a TC-L-CANCEL indication, the SACF shall: 

if the associated operation is a class 1 operation, inform the application process; 

if the associated operation is a class 2 operation and no linked operations are defined for this operation, ignore 
the primitive; 

if the associated operation is a class 2 operation and has Unked operations but none of them has been invoked, 
inform the application process; 

if the associated operation is a class 2 operation and a linked operation invocation has already been received in 
response to this operation, ignore the primitive; 

if the associated operation is a class 3 operation, inform the application process; 

if the associated operation is a class 4 operation, ignore the primitive. 

10.8.5 Other events 

This subclause describes the behaviour of SACF on receipt of a component handling indication primitive which cannot 
be related to any operation or which does not affect a pending one. 

1 0.8.5.1 Receipt of a TC-U-REJECT 

On receipt of a TC-U-REJECT indication primitive which does not affect an active operation (i.e. indicating a return 
result or return error problem), it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 10.2. This is also 
applicable for invoke problems related to a class 4 linked operation. 

1 0.8.5.2 Receipt of a TC-R-REJECT indication 

On receipt of a TC-R-REJECT indication (i.e. when a protocol error has been detected by the peer TC entity) which 
does not affect an active operation, it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 10.2. 

1 0.8.5.3 Receipt of a TC-L-REJECT indication 

On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) 
which cannot be related to an active operation, it is up to the application process to continue, or to terminate the 
dialogue and implicitly trigger the transmission of the reject component or to abort the dialogue. 

1 0.8.5.4 Receipt of a TC-NOTICE indication 

This informs the SACF that a message cannot be delivered by the Network Layer, this can only occur if the Return 
Option has been set (see subclause 10.9.1.8). It is for the application process to decide whether to terminate the dialogue 
or retry. 

1 0.9 Mapping on to TC services 
10.9.1 Dialogue control 

The TC-UNI service is not used by CAP. 

10.9.1.1 Destination address 

This parameter is set by the dialogue initiating application process, and may optionally be modified by the responding 
dialogue in the first backward TC-CONTINUE. 
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10.9.1.2 Originating address 

This parameter is set by the dialogue initiating application process. 

10.9.1.3 Dialogue ID 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. 

1 0.9.1 .4 Application-context-name 

The application-context-name parameter is set by SACF as defined in subclause 6.4. 

10.9.1.5 User information 

This parameter may be used by both initiating and responding application processes. The receiving side may ignore this 
parameter if received. The User Information parameter shall be encoded in accordance with the definition provided in 
Q.773 (section 3.2) and the definition of EXTERNAL type provided in X.690, with the restriction that an Object 
Identifier shall always be present to identify the user information and the entity which sent it. 

1 0.9.1 .6 Component present 

This parameter is used by SACF as described in ETS 300 287 [3] (ITU-T Recommendation Q.771). 

10.9.1.7 Termination 

The value of the release method parameter of the TC-END request primitive is set by SACF according to the rules as 
stated in subclauses 10.1 and 10.2. 

1 0.9.1 .8 Quality of service 

The quality of service of TC request primitives is set by the SACF to the following value: 
sequencing requested if required by the application (see subclause 4.4.2); 
- return option as required by the application (see subclause 4.4.2). 

10.9.2 Operation procedures 

10.9.2.1 Invoke ID 

This parameter is set by the sending application process. 

10.9.2.2 Linked ID 

This parameter is set by the sending application process. 

10.9.2.3 Dialogue ID 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. 

10.9.2.4 Class 

The value of this parameter is set by SACF according to the type of the operation to be invoked according to 
subclause 6.1. 
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10.9.2.5 Operation 

The operation code of a TC-INVOKE request primitive is set by the sending appHcation process as defined in 
subclause 6.4. 

S ACF shall set the operation code of the TC-RESULT-L primitive (if required) to the same value as the one received at 
invocation time. 

10.9.2.6 Error 

The error parameter of the TC-U-ERROR request primitive is set by the sending application process as defined in 
subclause 6.4. 

10.9.2.7 Parameters 

The argument parameter of TC-INVOKE primitives is set by the sending application process as defined in 
subclauses 6.1 and 6.3. 

The result parameter of TC-RESULT-L primitives is set by the sending application process as defined in subclauses 6.1 
and 6.3. 

The parameter of TC-U-ERROR primitives are set by the sending application process as defined in subclauses 6.2 and 
6.3. 

10.9.2.8 Timeout 

The value of this parameter is set by S ACF according to the type of operation invoked. 

10.9.2.9 Last component 

This parameter is used by SACF as described in ETS 300 287 [3] (ITU-T Recommendation Q.771). 

10.9.2.10 Problem code 

This parameter is used by SACF as described in subclause 10.8. 
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Annex A (normative): 

Mapping between CAP and ISUP 



This annex defines the mapping between the CAP parameters and the call parameters sent/received in the ISUP. The 
functional handling of these parameters is defined in GSM 03.78 [16]. 



A.1 InitialDP operation 



Table A.I 



ISUP message 
JAM (Note 1) 


CAP operation 
InitialDP 


Called party number 


calledPartyNumber 


Calling party number 


callingPartyNumber 


Calling party's category 


callingPartysCategory 


Location number 


locationNumber 


Original called number 


originalCalledPartylD 


User teleservice information (T' priority) 

High layer compatibility IE contained in access transport 
(2"'' priority) (Note 2) 


highLayerCompatibility 


Generic number 'additional calling party number' 


additionalCallingPartyNumber 


User service information prime (T' priority) 
User service information (2"'' priority) 


bearerCapabiUty 


Redirecting number 


redirectingPartylD 


Redirection information 


redirectionlnformation 



NOTE 1: Optional parameters may be absent, i.e. they are only mapped, if these parameters are available at the DP. 

NOTE 2: If two high layer compatibility information elements are contained in the access transport parameter, then 
the second information element, carrying the preferred HLC, is mapped to the CAP 
highLayerCompatibility parameter. 



A.2 Connect operation 



On receipt of a Connect operation from the gsmSCF the called party number used for routing is derived from the 
destinationRoutingAddress (see Table A.2). If the triggering of the CAMEL service was made for a mobile terminating 
or forwarded call, an ACM message shall be sent to the preceding exchange. The encoding of the backward call 
indicators in the ACM is specified in GSM 09.12 [24]. 

Table A.2 illustrates the mapping of parameters received in the Connect operation to parameters sent in the lAM 
message to the succeeding exchange. Parameters which were received in the lAM and are not replaced by parameters of 
the Connect operation are treated according to the normal procedures. 

On sending of the lAM the awaiting address complete timer is started. If the timer expires the call is released in both 
directions and an appropriate indication is returned to the calling subscriber. 
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Table A.2 



CAP operation 
Connect (Note 1) 


ISUP message 
lAIVI 


destinationRoutingAddress 


Called party number 






originalCalledPartylD 


Original called number 


callingPartysCategory 


Calling party's category 


redirectingPartylD 


Redirecting number 


redirectionlnformation 


Redirection information 


genericNumbers 


Generic number (Note 2) 



NOTE 1: Optional parameters may be absent, i.e. they are only mapped, if received. 

NOTE 2: The set of generic numbers received in the genericNumbers parameter is mapped to the appropriate 
number of Generic Number parameters in the ISUP lAM. This shall be performed irrespective of the 
value of the screening indicator in the ISUP calling party number. 



A.3 AssistRequestlnstructions operation 

If an lAM is received at an assisting SSP containing a gsmSSF or an IP containing a gsmSRF then an 
AssistRequestlnstructions operation is sent to the gsmSCF. The correlationID parameter in the 
AssistRequestlnstructions operation can contain: 

a) the CorrelationID digits extracted from the lAM Called Party Number, 

b) the whole Called Party Number received in the ISUP lAM (CorrelationID digits extracted at gsmSCF), 

c) the contents of the ISUP lAM CorrelationID parameter 

In the case where the gsmSCF and the assisting gsmSSF are both in the HPLMN and ISUP 97 is supported then any of 
these mechanisms may be used. 

In the case where the gsmSCF and the assisting gsmSSF are both in the HPLMN and ISUP 97 is not suported then 
mechanisms a) and b) may be used. 

In the case where the gsmSCF is in the HPLMN and the assisting gsmSSF is in the VPLMN then only mechanism b) 
may be used when an all-ISUP 97 signalling path cannot be guarenteed. Mechanism a) may be used if bilateral 
agreements on the format of the information transferred in the ISUP lAM Called Party Number are defined between the 
HPLMN and VPLMN. 

In the case where the gsmSCF is in the HPLMN and the assisting gsmSSF is in the VPLMN then mechanism c) only 
may be used if an all-ISUP 97 signalling path can be guarenteed between the HPLMN and the VPLMN. 



A.4 ConnectToResource operation 

On receipt of a ConnectToResource operation from the gsmSCF the the IP is connected to the incoming call, to facilitate 
User Interactive dialogue with the user. 

If the User Interactive dialogue is to be performed at a forwarding MSC or GMSC then an ACM message shall be sent 
to the preceding exchange. The encoding of the backward call indicators in the ACM is specified in GSM 09.12 [24], 
with the Optional Backward Call Indicators indicating 'in-band information or an appropriate pattern is now available'. 

If the User Interactive dialogue is to be performed at a forwarding MSC or GMSC then when the IP indicates through- 
connection and the ConnectToResource operation indicates that a bothway throughconnection is required an ANM 
message shall be sent to the preceding exchange if answer has not previously been sent. As a network 
operator/equipment vendor option a CPG message may be sent if ANM has already been sent. 
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A. 5 EstablishTemporaryConnection operation 

On receipt of an EstablishTemporaryConnection operation from the gsmSCF then if the triggering of the CAMEL 
service was made for a mobile terminating or forwarded call an ACM message shall be sent to the preceding exchange. 
The encoding of the backward call indicators in the ACM is specified in GSM 09.12 [24. In addition, an ISUP lAM 
shall be sent to the succeding exchange. 

Table A. 3 illustrates the mapping of parameters received in the EstablishTemporaryConnection operation to parameters 
sent in the lAM message to the succeeding exchange. On sending of the JAM the awaiting address complete timer is 
started. If the timer expires the call is released in both directions and an appropriate indication is returned to the calling 
subscriber. 

Table A.3 



CAP operation 
EstablishTemporaryConnection (Note 1) 


ISUP message 
JAM 


assistingSSPIPRoutingAddress 


Called party number 






correlationID 


Correlation id (note 1) 


scfid 


SCFid (note 1) 



NOTE 1: These optional parameters may be absent, i.e. they are only mapped, if received. If they are received and 
cannot be mapped then an error is sent to the gsmSCF as detailed in Section 9.15 

NOTE 2: The AssistingSSPIPRoutingAddress parameter may also include a Hex B digit, in order to delineate the 
boundary between digits used for routing and digits forming part of the SCFiD and/or CorrelationID. 

Except for the Called Party Number the remaining mandatory lAM parameters are set as follows: 

a) Nature of connection indicators 

Satellite indicator: set as in an Originating MSC, 

Continuity check indicator: set as in Originating MSC, 

Echo control device indicator: set as in Originating MSC 

b) Forward Call Indicators 

National/international call indicator: set as in Originating MSC, 

End-to-end method indicator: 00 (no end-to-end method available), 

Interworking indicator: (no interworking encountered). 

End-to-end information indicator: (no end-to-end information available), 

ISDN User Part indicator: 1 (ISDN User Part used all the way), 

ISDN User Part preference indicator: 00 (ISDN User Part preferred all the way), 

ISDN access indicator: (originating access non-ISDN), 

SCCP method indicator: 00 (no indication) 

c) Calling Party's Category 
00001010 (ordinary subscriber) 

d) Transmission Medium Requirement 
00000011 (3.1 kHz audio) 

The ISUP lAM optional parameter Propagation Delay Counter is set as in an Originating MSC 
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A.6 ReleaseCall operation 



Upon receipt of the ReleaseCall operation, the GMSC/gsmSSF (VMSC/gsmSSF) sends REL messages in both 
directions. The cause indicators parameter contains the releaseCallArg parameter of the ReleaseCall operation. 
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Annex B (informative): 
Change History 
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